總結今天內容，並學習SCTP協議總結其相比TCP的優勢！
TCP報頭詳解
各字段解釋：
源端口和目的端口，各佔2個字節，分別寫入源端口和目的端口；
32位序號，佔4個字節，TCP連接中傳送的字節流中的每個字節都按順序編號。
確認號，佔4個字節，是期望收到對方下一個報文的第一個數據字節的序號。
數據偏移，佔4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠；
保留，佔6位，保留今後使用，但目前應都位0；
緊急URG，當URG=1，表明緊急指針字段有效。告訴系統此報文段中有緊急數據；
確認ACK，僅當ACK=1時，確認號字段纔有效。TCP規定，在連接建立後所有報文的傳輸都必須把ACK置1；
推送PSH，當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應，這時候就將PSH=1；
復位RST，當RST=1，表明TCP連接中出現嚴重差錯，必須釋放連接，然後再重新建立連接；
同步SYN，在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；
終止FIN，用來釋放連接。當FIN=1，表明此報文的發送方的數據已經發送完畢，並且要求釋放；
窗口，佔2字節，指的是通知接收方，發送本報文你需要有多大的空間來接受；
檢驗和，佔2字節，校驗首部和數據這兩部分；
緊急指針，佔2字節，指出本報文段中的緊急數據的字節數；
選項，長度可變，定義一些其他的可選的參數。
TCP三次握手
• 第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）;
• 第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
• 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手;
未連接隊列
在三次握手協議中，服務器維護一個未連接隊列，該隊列爲每個客戶端的SYN包（syn=j）開設一個條目，該條目表明服務器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在服務器處於SYN_RECV狀態，當服務器收到客戶的確認包時，刪除該條目，服務器進入ESTABLISHED狀態。
TIME_WAIT狀態
TIME_WAIT狀態存在有兩個原因。
- 可靠終止TCP連接。如果最後一個ACK報文因爲網絡原因被丟棄，此時server因爲沒有收到ACK而超時重傳FIN報文，處於TIME_WAIT狀態的client可以繼續對FIN報文做回覆，向server發送ACK報文。
- 保證讓遲來的TCP報文段有足夠的時間被識別和丟棄。連接結束了，網絡中的延遲報文也應該被丟棄掉，以免影響立刻建立的新連接。
問題：爲什麼需要三次？
TCP是可靠的傳輸控制協議，三次握手能保證數據可靠傳輸又能提高傳輸效率。
如果TCP的握手是兩次：
<1>如果client發給server的SYN報文因爲網絡原因，延遲發送。由於client沒有收到server對SYN的確認報文，會重發SYN報文，服務器和回覆ACK，連接建立。數據發送完畢，這條連接被正常關閉。這時，延遲的SYN報文發到了server，server誤以爲這是client重新發送的同步報文，又回覆了一個ACK，和client建立了連接。
<2>如果server給client發送的ACK報文因爲網絡原因，報文被丟棄，此時server認爲已經建立好連接，但是client沒有收到確認報文，認爲沒有建立好連接。client會重發SYN報文，此時server已經處於就緒狀態，認爲已經建立好連接。
如果TCP的握手是四次：
- client給server發送SYN同步報文；
- server收到SYN後，給client回覆ACK確認報文；
- server給client發送SYN同步報文；
- client給server發送ACK確認報文。
第2、3步之間，server和client沒有任何的數據交互，分開發送相當於多發了一次TCP報文段，SYN和ACK標識只是TCP報頭的一個標識位。很明顯，這兩步可以合併，從而提高連接的速度和效率。
TCP四次握手
- 客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送
- 服務器B收到這個FIN，它發回一個ACK，確認序號爲收到的序號加和SYN一樣，一個FIN將佔用一個序號
- 服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A
- 客戶端A發回ACK報文確認，並將確認序號設置爲收到序號加1
爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，”你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
SCTP介紹
流控制傳輸協議（SCTP，Stream Control Transmission Protocol）是一種在網絡連接兩端之間同時傳輸多個數據流的協議。SCTP提供的服務於UDP和TCP類似，兼有TCP/UDP兩者特徵。
SCTP是爲傳輸信令業務流而制定的，它本身所具有的、優於TCP的一些先進協議機制，如選擇性重傳、無序遞交和支持多種網絡特性等，使得SCTP能夠在一定程度上滿足高性能傳輸的需求。而且，SCTP採用了類同TCP的流量控制機制，不存在類似基於UDP的實時媒體流對TCP性能造成的劣化干擾問題和公平性問題。因此，SCTP將有可能取代TCP，成爲下一代IP網上面向連接的可靠傳送層協議。
SCTP對比TCP
SCTP是可以確保數據傳輸的，和TCP類似，也是通過確認機制來實現的。和TCP不同的是：
1.TCP是以字節爲單位傳輸的，SCTP是以數據塊爲單位傳輸的
TCP接收端確認的是收到的字節數，SCTP接收端確認的是接收到的數據塊。SCTP的這種數據塊（被稱爲DATA CHUNK）通常會攜帶應用的一個數據包，或者說是應用要發送的一個消息。
與TCP不同，SCTP是將應用程序的每次調用sendmsg()發送的數據當作一個整體，放到一個被稱爲DATA CHUNK的數據塊裏面，接收端也是以DATA CHUNK爲單位接收數據，並重新組包，通知應用程序接收。通常，應用程序每次調用recvmesg()都會收到一條完整的消息。
在SCTP的發送端，多條短的應用層消息可以被SCTP協議打包放在同一個SCTP包中，此時在SCTP包中可以看到多個DATA CHUNK。另一方面，一條太長（比如，超過了路徑MTU）的應用層消息也可能被SCTP協議拆分成多個片段，分別放在多個DATA CHUNK並通過不同的SCTP包發送給對端。這兩種情況下，SCTP的接收端都能重新組包，並通知應用程序去接收。
2.TCP通常是單路徑傳輸，SCTP可以多路徑傳輸
TCP的兩端都只能用一個IP來建立連接，連接建立之後就只能用這一對IP來相互收發消息了。如果這一對IP之間的路徑出了問題，那這條TCP連接就不可用了。
SCTP不一樣的地方是，兩端都可以綁定到多個IP上，只要有其中一對IP能通，這條SCTP連接就還可以用。
3.TCP是單流有序傳輸，SCTP可以多流獨立有序/無序傳輸
一條SCTP連接裏面，可以區分多條不同的流（stream），不同的流之間的數據傳輸互不干擾。這樣做理論上的好處是，如果其中某一條流由於丟包阻塞了，那隻會影響到這一條流，其他的流並不會被阻塞。但是實際上，如果某一條流由於丟包阻塞，其他的流通常也會丟包，被阻塞，最後導致所有的流都被阻塞，SCTP連接中斷。
在同一條stream裏面，SCTP支持有序/無序兩種傳輸方式，應用程序在調用sendmsg()的時候，需要指定用哪一條stream傳輸，以及指定這條要發送的消息是需要有序傳輸還是無序傳輸的。如果在傳輸過程中丟包，則有序傳遞模式可能會在接收端被阻塞，而無序傳輸模式不會在接收端被阻塞。
4.TCP連接的建立過程需要三步握手，SCTP連接的建立過程需要四步握手
TCP連接建立過程，容易受到DoS攻擊。在建立連接的時候，client端需要發送SYN給server端，server端需要將這些連接請求緩存下來。通過這種機制，攻擊者可以發送大量僞造的SYN包到一個server端，導致server端耗盡內存來緩存這些連接請求，最終無法服務。
SCTP的建立過程需要四步握手，server端在收到連接請求時，不會立即分配內存緩存起來，而是返回一個COOKIE。client端需要回送這個COOKIE，server端校驗之後，從cookie中重新獲取有效信息（比如對端地址列表），纔會最終建立這條連接。這樣，可以避免類似TCP的SYN攻擊。
應用程序對此感知不到，對應用程序來說，不管是TCP還是SCTP，都只需要在server端listen一個socket，client調用connect()去連接到一個server端。
5.SCTP有heartbeat機制來管理路徑的可用性
SCTP協議本身有heartbeat機制來監控連接/路徑的可用性。
前面說過，SCTP兩端都可以bind多個IP，因此同一條SCTP連接的數據可以採用不同的IP來傳輸。不同的IP傳輸路徑對應一條path，不同的path都可以由heartbeat或者是數據的傳輸/確認來監控其狀態。
如果heartbeat沒相應，或者是數據在某條path超時沒收到確認導致重傳，則認爲該path有一次傳輸失敗。如果該path的連續傳輸失敗次數超過path的連續重傳次數，則認爲該path不可用，並通知應用程序。如果一條連接的連續傳輸次數超過設定的“連接最大重傳次數”，則該連接被認爲不可用，該連接會被關閉並通知應用程序。