1. OSI四層和七層映射

區(qū)別：

1. 應用層，表示層，會話層合并為了應用層
2. 數(shù)據(jù)鏈路層和物理層合并為了網(wǎng)絡接口層

2. TCP和UDP的區(qū)別？

總結(jié)：
1 . TCP 向上層提供面向連接的可靠服務 ，UDP 向上層提供無連接不可靠服務。
2. UDP 沒有 TCP 傳輸可靠，但是可以在實時性要求高的地方有所作為。
3. 對數(shù)據(jù)準確性要求高，速度可以相對較慢的，可以選用TCP。
4. 應用方面UDP實時應用比如視頻直播等，TCP可靠傳輸比如大文件傳輸。
5. UDP面向報文（只是數(shù)據(jù)報文的搬運工，不會對數(shù)據(jù)報文進行任何拆分和拼接操作。），TCP字節(jié)流。
6. UDP頭部開銷小 8字節(jié)相比 TCP 的至少20字節(jié)要少得多，傳輸數(shù)據(jù)報文時是很高效的。

3. TCP詳解

1. tcp報文頭部

需要說明的：
源端口
目的端口
seq序號： 占4個字節(jié)，是本報文段所發(fā)送的數(shù)據(jù)項目組第一個字節(jié)的序號。在TCP傳送的數(shù)據(jù)流中，每一個字節(jié)都有一個序號。例如，一報文段的序號為300，而且數(shù)據(jù)共100字節(jié)，則下一個報文段的序號就是400。
ack確認序號： 占4字節(jié)，是期望收到對方下次發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號，也就是期望收到的下一個報文段的首部中的序號；確認序號應該是上次已成功收到數(shù)據(jù)字節(jié)序號+1。

注意：上述兩個序號有值有效的前提是標識為1
標識位：
1、URG：當URG=1時，注解此報文應盡快傳送，而不要按本來的列隊次序來傳送。與“緊急指針”字段共同應用，緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號，
使接管方可以知道緊急數(shù)據(jù)共有多長。
2、ACK：只有當ACK=1時，確認序號字段才有效；
3、PSH：當PSH=1時，接收方應該盡快將本報文段立即傳送給其應用層。
4、RST：當RST=1時，表示出現(xiàn)連接錯誤，必須釋放連接，然后再重建傳輸連接。復位比特還用來拒絕一個不法的報文段或拒絕打開一個連接；
5、SYN：SYN=1,ACK=0時表示請求建立一個連接，攜帶SYN標志的TCP報文段為同步報文段；
6、FIN：發(fā)端完成發(fā)送任務。

2. 滑動窗口（流量控制）

滑動窗口用于流量控制： TCP流量控制主要是針對接收端的處理速度不如發(fā)送端發(fā)送速度快的問題，消除發(fā)送方使接收方緩存溢出的可能性。。可以理解成接收端所能提供的緩沖區(qū)大小。字節(jié)數(shù)起始于確認序號字段指明的值（這個值是接收端正期望接收的字節(jié)。

思考1: 重復發(fā)送
第一步發(fā)送了[33, 43),如果這次發(fā)送[35, 45),那中間重疊部分不是發(fā)送了兩次,所以這里要 是全部重新發(fā)送還是只發(fā)送接收端沒有收到的數(shù)據(jù),如果全部發(fā)送那么重復
發(fā)送的數(shù)據(jù)接收端怎么處理。
這個下面快速重傳會講

思考2: 滑動窗口是否可是可靠性的保障？
一直傳輸數(shù)據(jù),直到數(shù)據(jù)發(fā)送完成。這么一來就保證數(shù)據(jù)數(shù)據(jù)的可靠性,因為如果某數(shù)據(jù)沒有獲取到,那么ack永遠不會跳過它。與其說是滑動窗口的可靠，不如說是ACK機制的可靠。

3. 校驗和

檢驗和覆蓋了整個TCP報文段：TCP首部和數(shù)據(jù)。這是一個強制性的字段，一定是由發(fā)端計算和存儲，并由收端進行驗證。

4. TCP擁塞

1. 流量控制是通過接收方來控制流量的一種方式；而擁塞控制則是通過發(fā)送方來控制流量的一種方式。
2. 發(fā)送方的讓自己的發(fā)送窗口

win=min(cwnd，接受端接收窗口大小）

說明: 發(fā)送方取擁塞窗口與滑動窗口的最小值作為發(fā)送的上限。
3. TCP擁塞控制的幾種方法：慢啟動，擁塞避免，快重傳和快恢復。

• 慢啟動不慢：1然后 指數(shù)增長
  cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變量，一旦cwnd>=ssthresh（大多數(shù)TCP的實現(xiàn)，通常大小都是65536）
• 慢啟動過程結(jié)束，擁塞避免階段開始；cwnd的值不再指數(shù)級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加
• 超時，重傳了一個報文段把ssthresh降低為cwnd值的一半。把cwnd重新設置為1。重新進入慢啟動過程。

4. 快速重傳

如果，包沒有連續(xù)到達，就ack最后那個可能被丟了的包，如果發(fā)送方連續(xù)收到3次相同的ack，就重傳。Fast Retransmit的好處是不用等timeout了再重傳,而是只是三次相同的ack就重傳。

比如：如果發(fā)送方發(fā)出了1，2，3，4，5份數(shù)據(jù)，第一份先到送了，于是就ack回2，結(jié)果2因為某些原因沒收到，3到達了，于是還是ack回2，后面的4和5都到了，但是還是ack回2因為2還是沒有收到，于是發(fā)送端收到了三個ack=2的確認，知道了2還沒有到，于是就馬上重轉(zhuǎn)2。然后，接收端收到了2，此時因為3，4，5都收到了，于是ack回6。

主要是為了避免一個問題就是當接收端發(fā)現(xiàn)2丟失之后我是否需要死等2，即使我先收到了3，4，5 ，等到超時再發(fā)送？ 快速重傳保證了，到我收到3， 4，5時不需要等2到超時，我就可以直接返回ack=2了，三次之后，發(fā)送端會自動重傳3。

5. TCP狀態(tài)機

沒啥好說的理解就行
三次握手
客戶端視角：
close 情況下，發(fā)起Connet,報文標志 syn , 狀態(tài)變?yōu)镾YN_SENT ,等待服務端返回ack (syn ack), 進入established, 之后再發(fā)ack，這時可以發(fā)送數(shù)據(jù)了（注意這個時候如果發(fā)數(shù)據(jù)可以添加syn）

服務端視角：
close 情況下，listen等待連接，收到連接后syn_recv 之后返回ack, 等待客戶端ack到established

四次揮手

• 客戶端視角：
  主動請求關(guān)閉，發(fā)送FIN這個時候客戶端不能發(fā)數(shù)據(jù)了，但是服務端可以發(fā)，進入FIN_WAIT1, 接收到 ACK ,進入FIN_WAIT2
  ,等待，服務端發(fā)送FIN， 這個時候進入TIME_WAIT(2MSL)，并返回ack給服務端

• 服務端視角：
  收到FIN 包， 回復ack ，進入CLOSE_WAIT, 這個時候還是可以發(fā)數(shù)據(jù)，不發(fā)了之后 發(fā)一個FIN標志的包，表示要關(guān)閉了， 進入 LAST_ACK， 收到客戶端的ACK之后CLOSE

為什么客戶端TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？

• 防止最后一個客戶端回復的ACK服務端沒有收到。服務端處于LAST_ACK狀態(tài)下的SOCKET可能會因為超時未收到ACK報文，而重發(fā)FIN報文。
• MSL 是 Maximum Segment Lifetime，報?最??存時間，它是任何報?在?絡上存在的最?時間，超過這個時間報?將被丟棄。

為什么握手不能是兩次？

為了防止服務器端開啟一些無用的連接增加服務器開銷
防止已失效的連接請求報文段突然又傳送到了服務端，因而產(chǎn)生錯誤。

• 總結(jié)就是防止開啟一些“異常端口”浪費，所謂異常就是，比如服務端返回的ack沒有收到，客戶端需要超時重連，這段時間服務端的端口白白占用了，或者惡意人員開了很多半連接的端口，浪費了端口。

什么是半連接隊列？

6. TCP的可靠性

TCP主要提供了

• 檢驗和
• 序列號/確認應答
• 超時重傳
• 最大消息長度
• 滑動窗口控制

等方法實現(xiàn)了可靠性傳輸。但是總結(jié)其實還是校驗和 序列號/確認應答

7. 什么是TCP粘包和拆包？

1. TCP 是面向流，沒有界限的一串數(shù)據(jù)。TCP 底層并不了解上層業(yè)務數(shù)據(jù)的具體含義，它會根據(jù) TCP 緩沖區(qū)的實際情況進行包的劃分，所以在業(yè)務上認為，一個完整的包可能會被 TCP 拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是所謂的 TCP 粘包和拆包問題。
2. 要發(fā)送的數(shù)據(jù)小于 TCP 發(fā)送緩沖區(qū)的大小，TCP 將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包。
3. 要發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包
4. 待發(fā)送數(shù)據(jù)大于 MSS（最大報文長度），TCP 在傳輸前將進行拆包。即 TCP 報文長度 - TCP 頭部長度 > MSS

那怎么解決呢？

• 發(fā)送端將每個數(shù)據(jù)包封裝為固定長度
• 在數(shù)據(jù)尾部增加特殊字符進行分割
• 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個字段聲明內(nèi)容體的大小。