1、TCP的誕生
為了保證網絡的通信暢通，在破壞了幾個結點之后還能繼續通信，產生了ARPANET：
ARPANET的一個下屬研究所發明了TCP/IP協議：
TCP/IP協議是一個相關的協議群：
2、TCP四次揮手
1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2）服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最后的數據）。
4）服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
3.close函數gdb追蹤斷點：
原來以為應該是叫做close的函數，不過嘗試之后發現未果。tcp關閉一個通信應該是直接使用的sys_close函數：
我們在sys_close打上斷點，並且追蹤到：
我們按照list的內容，去找到這個函數的定義：
這個地方調用了__close_fd函數，我們來跟蹤它，看看有什么結果：
我們會發現，這兩個函數似乎是成對出現的：
在客戶端建立好TCP之前，會遇到這兩個斷點各一次：
我們去找到它們的定義：
我們繼續：
此時捕捉到2個斷點：
再繼續：
整理一下思路：
能看得出來，確實是TCP四次揮手。
我們來看看fput函數：
發現這玩意出現的周期也和前面兩個一樣（廢話，前面兩個中有一個調用它的，能不一樣嗎？）
