Tcp（傳輸控制協議）Transmission Control Protocol
最近發現以前學tcp的時候，根本並沒有理解tcp，整理一下
當應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流，TCP則把數據流分割成適當長度的報文段，最大傳輸段大小（MSS）通常受該計算機連接的網絡的數據鏈路層的最大傳送單元（MTU）限制。之後TCP把數據包傳給IP層，由它來通過網絡將包傳送給接收端實體的TCP層。
TCP爲了保證報文傳輸的可靠。就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。
tcp報文格式如下:幫助我們理解tcp的建立連接過程和釋放連接過程
tcp三次握手：
第一次握手：服務器被動打開，客戶端主動建立連接，向服務器發送請求，請求包括syn+seq，這裏的syn=1是指1爲是，0爲否，表名tcp報文格式中的syn有意義，seq是報文中的32位序號，seq=x，表明在後面傳送數據時的第一個數據字節的序號是x。。此時客戶端進行syn-send狀態。
第二次握手：服務器收到客戶端的請求報文後，發送syn+ack+seq表名自己已收到請求信息。圖中寫的ACK=1對應的是與SYN處於同一位置的ACK標記置爲1，ACK=1，其上的確認序號ack纔有意義，此時的ack爲收到客戶端的seq+1。seq是自己選擇的。服務器進入syn-rcvd狀態
第三次握手：客戶端收到服務器的確認信息後，要跟服務器進行確認。發送ack+seq信息到服務器。seq爲第二次握手時ack也就是第一次握手的seq+1.雙方進入已建立連接狀態，establ-ished
三次握手時每次都有發送的報文都有不同的地方，以此進行判斷是那一次握手。
tcp斷開連接過程：
|
狀 態 |
描 述 |
|
CLOSED |
關閉狀態，沒有連接活動或正在進行 |
|
LISTEN |
監聽狀態，服務器正在等待連接進入 |
|
SYN RCVD |
收到一個連接請求，尚未確認 |
|
SYN SENT |
已經發出連接請求，等待確認 |
|
ESTABLISHED |
連接建立，正常數據傳輸狀態 |
|
FIN WAIT 1 |
（主動關閉）已經發送關閉請求，等待確認 |
|
FIN WAIT 2 |
（主動關閉）收到對方關閉確認，等待對方關閉請求 |
|
TIMED WAIT |
完成雙向關閉，等待所有分組死掉 |
|
CLOSING |
雙方同時嘗試關閉，等待對方確認 |
|
CLOSE WAIT |
（被動關閉）收到對方關閉請求，已經確認 |
|
LAST ACK |
（被動關閉）等待最後一個關閉確認，並等待所有分組死掉 |
SYN
SYN（synchronous）是TCP/IP建立連接時使用的握手信號，tcp建立連接的第一個握手是發送syn，因此在黑客攻擊中可利用第一次握手的機制向指定主機放鬆大量的請求，但不做迴應，就是半連接請求，耗費目的主機cpu和內存資源。達到攻擊的目的
三次握手中，第三次握手的必要性:
假定出現一種異常情況，即A發出的第一個連接請求報文段並沒有丟失，而是在某些網絡結點長時間滯留了，一直延遲到連接釋放以後的某個時間纔到達B，本來這是一個早已失效的報文段。但B收到此失效的連接請求報文段後，就誤認爲是A又發出一次新的連接請求，於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立了，這樣一直等待A發來數據，B的許多資源就這樣白白浪費了
四次揮手中，最後主機a發送報文信息後等待2msl的意義：
- 第一，爲了保證A發送的最有一個ACK報文段能夠到達B。這個ACK報文段有可能丟失，因而使處在LAST-ACK狀態的B收不到對已發送的FIN和ACK報文段的確認。B會超時重傳這個FIN和ACK報文段，而A就能在2MSL時間內收到這個重傳的ACK+FIN報文段。接着A重傳一次確認。
- 第二，就是防止上面提到的已失效的連接請求報文段出現在本連接中，A在發送完最有一個ACK報文段後，再經過2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。
