使用持久HTTP連接

Question

我們正在嘗試實現代理概念驗證，但是遇到了一個有趣的問題：由於TCP的魔力，單個HTTP連接可以而且確實應該發出多個請求，並且HTTP事務通過多個數據包發送，是否有可能從數據包中間開始的HTTP請求？

請記住，這不是關於瀏覽器可能進行優化的理論問題，而是它是否實際上發生在現實生活中。 如果有人可以向我指出是否可以這樣做以及是否可以多久發生一次書面參考，那就更好了。

澄清更新：我們知道，如果僅在HTTP層中工作，就不必理會這個問題，但是，我們試圖弄清楚是否可以通過首先在TCP層上工作來應用某些高級技術。

Answer 1

首先，TCP是基於流的協議，沒有數據包的概念。 HTTP本身可能具有某種消息或記錄定界符，而TCP沒有。

該頁面可能會有所幫助： HTTP事務的結構

從您的問題看來，您似乎認為從TCP套接字讀取的每個數據都是“數據包”。 實際上，每次讀取僅讀取緩沖區中的字節數，直到您請求的最大字節數，而沒有任何記錄或數據包的概念。

例如，假設您從套接字讀取了2048個字節，則可能有一個事務的尾端，接着是第二個響應的開始，直到讀取的數據的一半，而僅獲得第二個響應的其余部分。您下次從套接字讀取。

如果您在耶路撒冷或附近，也許我可以幫助您。

Answer 2

假設您在談論IP數據包：是的，HTTP請求可能從IP數據包的中間開始。

當您使用持久HTTP連接時 ，即對多個HTTP請求使用相同的TCP連接時，請求邊界很可能位於IP數據包的中間。

IP和HTTP之間還有一個TCP協議。 TCP還包含一些標頭，因此IP數據包可以以某些TCP標頭開頭，其余數據包由HTTP請求組成。

HTTP請求也可能包含幾個IP數據包（如果文件上傳，傳輸錯誤以及隨后的重傳等）。

但是，我想知道如果您在HTTP級別工作，為什么對包感興趣？ TCP應該隱藏IP數據包的詳細信息。

Answer 3

取決於您在談論數據包的哪個抽象層：HTTP下有許多層。

HTTP --> TCP (byte stream) --> IP (packet) --> (possibly something else) Ethernet (frame) --> (possibly) some other transport

如果您在談論IP層，那么HTTP層將在稍后開始。請注意，TCP向其客戶端層提供了“字節流接口”，因此這里沒有包的概念。

Answer 4

除非您實現自己的TCP堆棧，否則不必擔心數據包，而不必擔心TCP提供的API，對於POSIX接口，它將是recv（）或read（）。 因此，我將問題視為“可以將多個HTTP請求放入一個read（）中，並且可以在多個read（）請求之間拆分HTTP請求嗎？” -兩者的答案都是“是的，有可能”。

HTTP流水線是發生這種情況的一個示例。 在現實生活中這種情況並不常見（具有諷刺意味的是，至少某些瀏覽器默認由於“越野車代理”而禁用了它：-)-但是，當這種情況發生時，對於用戶來說可能是個問題，尤其是如果他們無權訪問代理。

在Debian衍生的linux系統中，默認情況下apt-get確實會發生這種情況的一個非常值得注意的地方。 只需安裝Debian或Ubuntu服務器，然后嘗試通過代理使用即可。 您可以通過編輯/etc/apt/apt.conf.d/proxy文件並在其中放置以下內容來做到這一點：

Acquire::http::Proxy "http://your.proxy.address:8080";

Answer 5

我想我知道您在嘗試解決這個問題。

如果您不使用持久性HTTP連接，則HTTP GET請求標頭始終是通過TCP連接發送的第一件事，因此我們可以確保HTTP GET請求標頭的開頭“不會在中間開始”一些TCP數據包”。 但是請記住，可能存在一個或多個沒有任何用戶數據的TCP數據包，例如僅一個SYN，這可能使TCP數據包以HTTP GET請求標頭的開頭。 還要記住，HTTP GET請求標頭可能不包含在單個TCP數據包中。

如果確實使用持久性HTTP連接，則請求號N + 1的HTTP GET請求標頭的開始可以在TCP數據包的中間開始，即在請求號N的HTTP GET請求主體結束之后。

如果您問這些問題，可能是“做錯了”。 正如其他一些響應者已經指出的那樣，在大多數情況下，您可能應該只是一個TCP客戶端，處理TCP數據流，並讓TCP代碼擔心TCP數據包。 （當然，除非您正在使用某些特殊的硬件，這些硬件正在查看各個IP數據包，因為它們會飛過並嘗試在HTTP層進行一些處理。）