Proxy forward nie zachowuje granic segmentów TCP
Oddziel segmentację TCP, odczyty gniazda i ramkowanie HTTP podczas badania ruchu po obu stronach proxy forward.
Załóżmy, że odpowiedź HTTP po przejściu przez Squida pojawia się w kilku przechwyconych segmentach TCP. To może być zwykłe zachowanie TCP, a nie dowód, że odpowiedź została podzielona niepoprawnie.
Proxy forward ma zwykle dwa połączenia:
client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ originKażde połączenie ma własny stan TCP, numery sekwencyjne i pakietowanie. Proxy może odczytywać dane z jednego połączenia i zapisywać je w drugim, nie zachowując pierwotnych rozmiarów segmentów. Buforowanie, moment wysyłki, przeciążenie i limity rozmiaru ścieżki mogą utworzyć inne grupowanie.
Trzy granice, które warto trzymać osobno
| Granica | Co ją określa |
|---|---|
| Segment TCP | Ścieżka transportowa i sieciowa |
| Wynik odczytu gniazda | Dostępne bajty strumienia i bufor wywołującego |
| Komunikat lub ramka HTTP | Zasady ramkowania protokołu HTTP |
Jeden odczyt może zawierać część nagłówka, cały nagłówek wraz z bajtami ciała albo dane przekraczające więcej niż jedną granicę na poziomie aplikacji. TCP nie przypina „końca odpowiedzi HTTP” do końca udanego odczytu.
Dlatego parser HTTP/1.1 gromadzi nagłówki i stosuje właściwe zasady ramkowania ciała, w tym długość, kodowanie transferu lub dozwolone zamknięcie połączenia. Ramka HTTP/2 to struktura protokołu, która sama może przekraczać segmenty TCP; nie jest inną nazwą pakietu sieciowego.
Udany tunel CONNECT zachowuje tunelowany strumień bajtów, ale nadal używa dwóch odcinków TCP. Jego granice segmentów mogą się różnić nawet wtedy, gdy proxy nie zmieniło bajtów wewnątrz tunelu.
Badając uszkodzenia, porównuj ponownie złożone dane aplikacji. Porównywanie liczby pakietów lub oczekiwanie identycznych długości pakietów po obu stronach wymaga od TCP gwarancji granic, której ono nie daje.