計算機是如何聊天的？

12-29

關於計算機是如何聊天的一書中提到的，整個通信過程發11個包，建立通信3個，雙向通信4個，拆除鏈接4個，其中雙向通信4個包不是很明白，麻煩精通此專業的大神指點迷津！謝謝@車小胖@網路高手@網路周扒皮

TCP協議是最難的一個協議，沒有之一，我在知乎上的回答了差不多有100個，但這遠遠不夠，因為好多話題還沒有涉及到。

這四次消息交互的過程是一個簡化版的理想模型，為了初學者有一個基本的概念。

假定三次同步握手完成，以下只討論接下來用戶數據傳輸過程，也不討論四次連接斷開。

1 客戶端將http get 發送出去

2 伺服器端TCP對1確認

3 伺服器端把網頁發送出來

4 客戶端TCP對3確認

為何伺服器端不把2、3合併，用一個報文發出來？

那是因為TCP進程（內核進程）需要等待伺服器進程（用戶進程）完全生成網頁才能發出，這個等待過程有點耗時，而客戶端有可能超時重傳，為了避免這種情況的發生，需要TCP進程立馬確認客戶端，而不能等網頁返回（伺服器生成好）再確認。

之所以說以上是一個理想模型，是因為我們忽略了丟包、超時重傳，還忽略了一點，網頁很大，一個TCP包無法容納，可能需要十個以上TCP報文才可以傳輸完畢，那同學們肯定會擔心，客戶端如何知道這個網頁有多大尺寸，這個http協議里自然就有長度欄位，所以各位無需多慮。

如果伺服器端發出10個TCP報文，是否意味著客戶端要確認10次？當然這麼做也沒錯，但會產生太多的ACK報文，於是TCP協議規範里，又有了一個新的名詞 Delayed ACK。

什麼意思呢？

就是讓接收方等待200毫秒，如果在等待過程中，又接到對方的TCP報文，那麼就接到兩個，發送一個確認；

如果在等待過程沒有接到更多的TCP報文，那麼一旦200毫秒超時，就發送確認，而無需繼續等待。

關於這個可以參考另一篇回答，可能有點難：

https://www.zhihu.com/question/57856855/answer/220858155

接下來是廣告位，不喜就此打住

凡是別人說過的觀點不會出現在我的回答中，我獨創一套自學計算機網路技術學習方法，對抽象話題從生活里找靈感，將抽象話題簡化為具體的生活細節，一旦概念正確、清晰，則其背後原理只剩下，一個個人為制定的遊戲規則。

歡迎來參加我的第一個live

https://www.zhihu.com/lives/897123723914649600

那就看《自頂向下方法》吧，我之前是網路小白，看這個清晰了不少。

同時也做了書里的編程練習，覺得有用就看看吧。

moranzcw/Computer-Networking-A-Top-Down-Approach-NOTES

關於題主的問題, 希望你好好看看tcp/ip詳解這本書, 好好看完這本書的核心章節, 基本上無論是面試還是平時應用, 你都不會再有此類疑問. 看書, 比其他人的二手消息要靠譜很多. tcp/ip詳解之所以出名, 就是因為他解釋的很通俗明了又詳細.

接下來是我回答這個問題的初衷:

強烈反對高票答案 @車小胖的回答.

我在評論中問了一句那個delayed ack的"200ms是你拍腦袋想出來的嗎", 他直接關了我的評論.

通過製造權威感, 營造沒人反對的表象, 這種圈粉方式, 作為一個靠事實和數據說話的工程師, 是看不下去的.

另外提一句, delayed ack, 並沒有規定說要200ms才行, 他就是在拍腦袋. 200ms這個數字直覺來看就知道偏大了. 紅帽的linux的delayed ack, 默認是40ms

2.13. Reducing the TCP delayed ack timeout

如果一個人對技術方面的問題如此草率, 不依靠數據而是靠所謂的"聲望"來支撐自己的觀點, 我認為諸位看客要提高警覺性, 因為你們難免哪天就會被這類人的錯誤數據誤導到.

客觀事實不怕反駁, 反而是理越辯越明. 不敢接受異議的人, 不是自己心虛是什麼?!

另外他說的http里自然攜帶了網頁尺寸多大的說法也是錯誤的.

HTTP當中有個東西叫做chunked transfer encoding Chunked transfer encoding | Wikiwand

即伺服器端的http response可能並不會預先在http header裡面標明response的尺寸. 一般使用這種應用的場景是一些streaming應用.

我舉個例子, 以前在百度盤或者115之類的網盤裡一次選擇多個文件進行下載的時候, 伺服器可能會把這幾個文件打包成一個zip包(雖然實際上根本沒有任何壓縮處理, 只是改了下格式, 加了zip的header), 這種情況下, 你瀏覽器下載的時候, 很可能就看不到預期的打包文件的大小. 如果出現這種情況, 基本上可能就是用了chunked transfer encoding.

我對http並不是很熟悉, 也從來沒做過http協議的web開發, 即使這樣, 我都知道他說的某些東西是錯誤的.

對於圈粉搞營銷的人, 一定要提高警惕.

現在動不動阿貓阿狗也要開開live賺點錢了, 因為小白肉雞實在太多. 知乎是真正的劣幣驅逐良幣, 大多數人喜歡搞偶像崇拜, 對"事實"這個東西往往會忽略.

前提是tcp協議吧，抓個包看看伺服器和客戶端怎麼握手，怎麼通訊的。什麼fin什麼ack。

計算機網路原理第六版