TCP的位置
TCP工作在網路OSI的七層模型中的第四層——Transport層，IP在第三層——Network層，ARP在第二層——Data Link層；
在第二層上的資料，我們把它叫Frame，在第三層上的資料叫Packet，第四層的資料叫Segment。
資料從應用層發下來，會在每一層都會加上頭部資訊，進行封裝，然後再傳送到資料接收端。這個基本的流程你需要知道，就是每個資料都會經過資料的封裝和解封裝的過程。 在OSI七層模型中，每一層的作用和對應的協議如下：
3次握手
第一次握手：主機A傳送位碼為syn＝1,隨機產生seq number=x的資料包到伺服器，客戶端進入SYN_SEND狀態，等待伺服器的確認；主機B由SYN=1知道，A要求建立聯機；
第二次握手：主機B收到請求後要確認聯機資訊，向A傳送ack number(主機A的seq+1),syn=1,ack=1,隨機產生seq=y的包,此時伺服器進入SYN_RECV狀態;
第三次握手：主機A收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，主機A會再傳送ack number(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則連線建立成功。客戶端和伺服器端都進入ESTABLISHED狀
態，完成TCP三次握手。
TCP位碼,有6種標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)
Sequence number(順序號碼) Acknowledge number(確認號碼)
4次揮手
第一次揮手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；
第二次揮手：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我也沒有資料要傳送了，可以進行關閉連線了；
第三次揮手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入CLOSE_WAIT狀態；
第四次揮手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。
問題
1.為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
雖然按道理，四個報文都傳送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網路是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
2.client傳送完最後一個ack之後，進入time_wait狀態，但是他怎麼知道server有沒有收到這個ack呢？莫非sever也要等待一段時間，如果收到了這個ack就close，如果沒有收到就再發一個fin給client？這麼說server最後也有一個time_wait哦？求解答！
因為網路原因，主動關閉的一方傳送的這個ACK包很可能延遲，從而觸發被動連線一方重傳FIN包。極端情況下，這一去一回，就是兩倍的MSL時長。如果主動關閉的一方跳過TIME_WAIT直接進入CLOSED，或者在TIME_WAIT停留的時長不足兩倍的MSL，那麼當被動
關閉的一方早先發出的延遲包到達後，就可能出現類似下面的問題：1.舊的TCP連線已經不存在了，系統此時只能返回RST包2.新的TCP連線被建立起來了，延遲包可能干擾新的連線，這就是為什麼time_wait需要等待2MSL時長的原因。
收集整理自：（果凍想還有TCP首部，TCP Flags，3次握手4次分手原因詳細解釋，必看必看）