今天剛看完《計算機網路——自頂向下方法》這本書的運輸層這一章。直到今天我才知道，tcp協議居然有這麼複雜（之前上課都沒怎麼認真聽），這一章節總共七十多頁，主要介紹udp與tcp，但udp的內容卻只佔不超過5頁，大部分的篇幅都是在講解tcp的機制。但是就算這樣，我還是感覺這本書對tcp的講解不夠詳細，忽略了很多內容和細節，導致我無法將這本書對tcp的講解串通在一起，感覺前後矛盾，同時也有很多地方無法理解。這一章讀下來，我對tcp有了更深入的了解，但是同時也對它有了更多的疑問。由此看來，想要真正弄懂tcp，不能僅僅依靠這種入門書籍，應該選擇一些專門講解這一塊內容的書籍進行研究。
接下來我準備將這幾天看的tcp的內容進行一次總結，以部落格的形式將這些內容記錄下來，算是加深印象吧。這篇部落格就先來說一說tcp的三次握手和四次揮手，也就是tcp連線的建立與斷開，算是tcp中相對比較簡單的部分。
想要了解tcp的三次握手與四次揮手，首先得了解一下tcp的報文格式，因為這兩個過程需要依賴tcp報文中的一些字段。下面我們通過一幅圖來講解tcp的報文格式：
我只介紹tcp報文中，與三次握手和四次揮手有關的部分：
對於tcp報文格式，就先介紹這麼多，其餘的部分雖然也很重要，但是並沒有作用於tcp連線的建立與斷開，所以就不在這裡敘述了。
tcp建立連線的過程中需要傳送三次報文，所以tcp建立連線也被稱為三次握手，接下來我就來講講這三次握手的過程，假設客戶端向伺服器發起tcp連線：
首先我們要明確，兩次握手是必要的。第一次握手，客戶端將syn報文傳送到伺服器，伺服器接收到報文後，即可確認客戶端到伺服器是可達的；而伺服器向客戶端傳送響應的synack報文，客戶端接收到後，即可確認伺服器到客戶端也是可達的。至此，連線已經算是建立，那為什麼還要有第三次握手呢？
客戶端和伺服器的握手過程，不僅僅是確認互相可達的過程，更重要的是乙個同步的過程，syn就是同步（synchronize）的縮寫。對於tcp報文段來說，序號是乙個至關重要的部分，它保證了tcp傳輸資料的完整性。而我們上面也說過，tcp報文的初始序號不是從0開始的，而是乙個隨機的序號，而所謂的同步，就是tcp客戶端和伺服器互相同步初始序號的過程。第一次握手，客戶端傳送syn報文，將自己的初始序號傳送到了伺服器，伺服器接收到後，向客戶端傳送synack報文段，告訴客戶端已經收到了它的初始序號，同時在這個報文段中帶上了自己的初始序號。這個時候，第三次握手的作用就出來了：第三次握手實際上就是客戶端在告訴伺服器，自己已經收到了它的初始序號，完成了同步，可以開始相互傳輸資料了。若沒有第三次握手，伺服器將無法保證客戶端接收到了自己的synack報文段，若此時synack報文段丟失，客戶端不知道伺服器的初始序號，將無法處理之後到達客戶端的資料。
在很多書籍和網上的部落格中還流傳另外一種說法。若僅僅是兩次握手，將產生以下問題：客戶端向伺服器傳送syn報文段請求建立連線，但是沒有在指定時間內收到synack報文段，所以客戶端認為syn報文段在網路中丟失，則再次傳送syn報文段，並成功接收到了synack報文段，但是客戶端在很短的時間內就斷開了tcp連線。然而，最初的syn報文並沒有丟失，只是傳輸時延太長，過了許久才到達。等它到達伺服器時，其實客戶端已經與伺服器建立過tcp連線，並且已經斷開了。此時伺服器接收到這條syn報文段，以為客戶端又想建立一條新的連線，於是向客戶端回送ack報文，並為連線分配了資源。由於沒有第三次握手，伺服器將不知道這其實是上一次連線的報文，於是將它建立乙個新的tcp連線並維持，直至因為太久沒有接收到資料而釋放。這種情況非常浪費資源，所以為了防止這種情況的發生，才需要客戶端的再一次確認。
實際上，上面所述的第一點才是tcp三次握手的原因，第二個只能算是順帶的好處吧，從建立連線的報文被稱為syn（同步）就可以看出這點。
說完了三次握手，下面來說說四次揮手的過程。tcp在斷開連線時，客戶端與伺服器之間要交換四次報文，所以，tcp的斷開連線也叫四次揮手。
以上就是四次揮手的過程，相對建立連線來說要簡單一些。以上是以客戶端請求斷開連線來舉例，但其實也可以由伺服器斷開連線。
看完上面四次揮手的過程，可能有的人會有疑問，四次揮手之後，連線不是已經斷開了嗎，為什麼客戶端還要等待一段時間再釋放資源呢？原因有兩個：
有的人可能也會想，斷開連線為什麼是四次揮手，不能是兩次呢？其中一方請求斷開連線，另一方確認即可，為什麼這個過程需要兩邊各發起一次？原因就是：tcp連線是全雙工的。什麼是全雙工，即a與b建立連線，則a可以向b傳送資料，而b也可以向a傳送資料。
我們知道斷開連線的請求什麼時候發起？當然就是在不再有資料需要傳送時。我們依舊以客戶端向伺服器斷開連線為例。假設客戶端和伺服器建立了乙個tcp連線，在客戶端需要向伺服器傳送的資料都傳送完後，客戶端就可以向伺服器傳送乙個fin報文段，請求斷開連線；伺服器接收到後，將會回送乙個ack報文，告訴客戶端，自己已經收到了它斷開連線的請求。若只有兩次揮手，這個時候連線就算是斷開了。但是這樣真的合理嗎？答案當然是否定的。
客戶端傳送完資料後，告訴伺服器，我沒有資料了，可以和你斷開，但是不代表伺服器沒有資料需要傳送到客戶端了呀。tcp是乙個全雙工的連線，代表伺服器也有可能有資料需要傳送到客戶端。所以，只有當兩端的資料都傳送完畢，連線才能安全的斷開。因此，伺服器接收到了客戶端的fin報文段，他會等到自己所有的資料傳送完，然後也向客戶端傳送乙個fin報文，告訴客戶端我也沒資料了，這時候連線才能真正斷開，兩端各自釋放資源。
以上對tcp的三次握手和四次揮手做了乙個比較全面的講解，相信看完之後可以讓人對tcp連線的建立和斷開有更深入的理解。但是，這一部分內容實際上只是tcp中比較簡單的一塊，儘管如此，還是用了這麼多篇幅去講解，可想而知tcp的複雜性。我後面還將寫幾篇關於tcp其他方面的內容，希望在蒐集資料和編寫的過程中，能夠加深我對它的理解。
《計算機網路——自頂向下方法（原書第七版）》
多篇部落格
計算機網路（四），TCP三次握手
1.三次握手詳情 2.為什麼需要三次握手才能建立連線 3.首次握手的隱患 syn超時的問題 4.建立連線之後，client出現故障 1 一開始，客戶端和伺服器端都處於關閉狀態 closed 然後開啟服務，服務端這個時候處於監聽狀態 listen 2 客戶端傳送乙個連線請求報文，裡面syn等於1，se...
計算機網路之tcp三次握手
客戶端與伺服器之間資料的傳送和返回的過程當中需要建立乙個叫tcp connection的東西 由於tcp不存在連線的概念，只存在請求和響應，請求和響應都是資料報，它們之間都是經過由tcp建立的乙個從客戶端發起，伺服器接收的類似連線的通道，這個連線可以一直保持，http請求是在這個連線的基礎上傳送的 ...
計算機網路 三次握手
假設a為客戶端，b為服務端。首先b處於listen 監聽 狀態，等待客戶的連線請求。a向b傳送連線請求報文，syn 1,ack 0 選擇乙個初始的序號x b收到連線請求，如果同意建立連線，則向a傳送連線確認報文，syn 1,ack 1 確認號為1，同時也選擇乙個初始的序號y。a收到b的連線確認序號後...