1.UDP的格式

2.TCP的格式

3.TCP是來解決什么問題的？

答：

解決IP層的不可靠傳輸問題，可能數據包丟失、損壞、重復等

為上層應用層提高可靠有序的數據傳輸服務

通過校驗和、確認應答機制、序列號來解決不可靠傳輸和無序性問題

通過流量控制--->>滑動窗口來解決發送發送方和接受方的消息接受能力問題

通過擁塞控制--->>慢啟動/擁塞窗口來解決因網絡問題導致大面積丟包的問題

4.TCP和UDP的核心區別？

答：

TCP是面向連接的(需要提前建立連接)、面向字節流的

UDP是無連接的(可以直接發送)、面向數據報的

TCP報頭最小20字節，20-60字節

UDP報頭固定8字節

TCP有重傳機制、可靠性高、有確認應答、超時重傳、快重傳、序列號、校驗和、流量控制、擁塞控制

UDP僅有校驗和，可靠性不高，適合延遲低的，實時性高的

5.TCP和UDP的應用場景？

答：

TCP web訪問 文件傳輸 數據庫連接 郵件等

UDP 直播 在線游戲如移動位置，對歷史位置不感興趣 DNS 高頻交易 局域網廣播等

6.UDP頭部為什么沒有首部長度字段？

答：

UDP報頭長度固定8字節，避免復雜結構，固定長度提高效率

7.TCP頭部格式？為什么需要TCP協議？

答：

????????兩個16位端口號

????????16位窗口大小

????????16位緊急指針

????????16位校驗和

????????4位首部長度

????????6個標志位

????????6個保留位

選項

有效載荷

為什么需要：保證數據傳輸的可靠性 安全性 又快又穩，解決丟包亂序重復等問題

8.TCP工作在哪一層？

答：

傳輸層 網絡層上面 應用層下面 負責數據的傳輸

9.服務器監聽一個端口，TCP“最大連接數“怎么計算？

答：

理論上無上限、單機主機64K個、每個連接占用一個fd,可能取決fd的上限

每個客戶端有約三萬個端口、所以單個客戶端能發送3萬個連接

還取決于內存 因為每個TCP連接都要管理起來

10.TCP的粘包、拆包機制是什么？

答：

TCP是面向字節流的，粘包是指報文之間沒有邊界，數據都在緩沖區里一塊放著，讀取是讀取定長數據，可能讀取半塊也可能一塊半，簡單來說粘包就是多個數據被合并接受

TCP有Nagle算法優化 會新緩存一部分數據再發送，導致粘包，如果對方未及時讀取，可能導致數據堆在一起

拆包是對報文拆成多段發送，可能由于報文長度過大，分開發，也可能對方緩沖區小，先發一部分

11.如何解決粘包、拆包？

答：

固定長度協議、在頭部添加數據長度、用分隔符分割

12.說說TCP的三次握手？

答：

---》客戶端connect發起連接---》發送SYN報文 進入SYN_SENT狀態

---》服務器收到SYN報文---》回復SYN+ACK，進入SYN_RCVD狀態，連接放入半連接隊列

---》客戶端收到SYN+ACK---》客戶端發送ACK并進入連接狀態

---》服務器收到ACK---》從半連接放入全連接隊列并進入連接狀態

如果SYN丟失，重發，對面無感知

如果SYN+ACK丟失，客戶端認為丟包，重發SYN

如果最后的ACK丟失，服務器發送RST給客戶端 進行重新連接

13.為什么必須TCP三次握手？

答：

兩次的話，對方無法確認是否收到SYN+ACK

四次的話沒必要，因為有捎帶應答機制

14.什么是半連接隊列？作用？

答：

半連接隊列相當于緩沖池

如果有大量請求到來，先將一部分放入半連接隊列，防止有的連接被丟棄

15.什么是SYN Flood攻擊？如何解決？

答：

因為TCP三次握手，有人惡意攻擊，頻繁發起SYN請求，但是不進行ACK應答

因為服務器必須要接受連接，所以每個SYN請求都會接受，導致半連接隊列滿了，其他請求進不來了

解決：調整半連接隊列容量、超時斷開、限速、防火墻

16.為什么需要四次揮手？

答：

為什么不是三次呢？--》被動方可能不想斷開，所以需要一來一回

有可能有未處理完的數據傳輸，確保對方都收到終止信號防止資源泄露

17.除了四次揮手，還有什么辦法斷開連接？

答：

RST標志位置1，表示重置連接，一端如果一旦收到 RST立即丟棄所有已緩存數據，并進入closed狀態，并向應用層返回錯誤，屬于急迫中斷，不會等待對方的確認，常用于程序突然關閉，網絡突然中斷的情況

收到非法報文，無效的序列號

半連接隊列超時

連接超時強制斷開

18.四次揮手各報文丟失會怎樣？

答：

重傳，直到應答位置

第一次揮手發送FIN報文并且進入FIN_WAIT1狀態，等待對方的ACK響應

如果對面的ACK響應沒收到（可能FIN丟失了，對方未收到，也可能對面的ACK丟包了），超過一段時間重傳FIN報文，直到收到ACK或者超過重傳最大次數（此時連接強制斷開）

第二次揮手應答ACK報文

如果收到了FIN，則進入CLOSE_WAIT狀態，然后發送ACK給對方，對方收到會進入FIN_WAIT2狀態，如果ACK報文丟失，對面會重傳FIN,如果收到重復的FIN，還會發送ACK即使處于CLOSE_WAIT狀態

第三次揮手FIN丟失

等待關閉的一方完成輸出處理后準備關閉了，發送FIN報文給對方，進入LAST_ACK狀態等待對方的ACK，若丟失，對面不知道你什么時候準備好關閉，會一直停留在FIN_WAIT2狀態

所以如果自己在LAST_WAIT狀態超時后，會重傳FIN報文，跟對方沒關系，對方不知道你什么時候準備好關閉

第四次揮手ACK丟失

收到FIN后進入TIME_WAIT狀態（等待2MSL時間，確保對方收到ACK）,最終關閉連接，對方收到ACK，進入closed狀態

如果丟失，主動方在TIME_WAIT狀態在收到重復的FIN會在此發送ACK,如果還是沒收到，2MSL后自動關閉

任何一個報文丟失都會通過超時重傳的機制來恢復

19.為什么四次揮手需要TIME_WAIT狀態？

答：

可能關閉后，還剩余一些報文沒有處理在網絡中

確保對方收到ACK，等待2MSL（報文最大生存周期，通常2分鐘），避免對方沒收到ACK,而重發FIN，如果對方真沒收到，對方重發FIN,還會發送ACK回去，直到對方收到
如果沒有time_wait狀態，最后一個ACK丟失了，被動方一直處于LAST_ACK狀態，連接無法正常關閉，資源泄露

防止舊報文干擾后續新連接
TCP連接由源Ip 源端口 目的ip 目的端口 四元組標識，當一個連接關閉，新連接可能復用相同的四元組（客戶端短時間內重新連接服務器的同一端口號）
如果上一個連接的被丟棄的舊報文還在網絡中，此時新連接可能收到這些“垃圾”數據，數據錯亂
time_wait等待2MSL保證了一個報文在網絡中的存活最大時間到期

總結：確保對方收到ACK、等待舊報文過期，防止干擾新鏈接

20.CLOSE_WAIT狀態持續時間過長的原因？

答：

服務器在close_wait狀態，沒正常調用關閉接口，比如阻塞住了，會長期占用資源

21.如果客戶端在time_wait狀態崩潰，會怎樣？

答：

服務器沒收到ACK,重發FIN報文，一直收不到回應，超時關閉連接，釋放資源

22.TIME_WAIT過多有什么危害？如何優化？

答：

導致端口耗盡、內存占用高

為什么產生：用戶頻繁連接斷開連接、產生大量的TIME_WAIT，都在等待2MSL時間，導致這段時間資源耗盡，導致文件描述符不夠了

如何優化：使用連接池，減少頻繁創建新鏈接、內核參數優化、縮短MSL時間、設置端口復用（即使處于MSL時間內，新連接仍然可以使用此連接）
關于端口復用的問題：端口復用只能用于四元組不相同，相同也會失敗

23.在TIME_WAIT狀態收到新SYN會怎樣？

答：

丟失此請求、判定為舊連接沖突
因為四元組相同 如果不同的話可以連接，不會沖突

24.已建立連接，客戶端突然斷電異常崩潰會怎樣？

答：

斷點不會發送FIN RST ，服務端還會認為正在連接狀態，定時發送心跳包探測，收不到應答會重發、到一定次數會關閉連接、也可能因為空閑時長太長發送報文探測，沒應答斷開

如果進程是突然崩潰的，，操作系統會替代進程進行四次揮手或者RST

25.TCP中何時會出現RST報文？

答：

服務器未開啟監聽，客戶端發起連接，服務器發回RST告知無法連接

連接已關閉但收到數據，一方處于正常關閉狀態CLOSED，但收到對方數據（可能是網絡延遲的舊數據）會回復RST報文，表示當前連接已失效

半連接隊列溢出，可能對新連接發送RST

收到非法報文、不是我的包或者序列號不對

應用程序強制關閉、資源耗盡、強制RST

攜帶URG位、但是緊急指針無數據 可能RST

26.TCP協議如何保證可靠傳輸？

答：

序列號去重

校驗和 判定報文正確

超時重傳

確認應答

滑動窗口

流量控制

擁塞控制

快重傳

捎帶應答

27.TCP超時重傳解決了什么問題？

答：

解決了數據丟包問題

28.有了超時重傳為什么還要有快重傳

答：

提高效率，超時重傳時間長

快重傳快速恢復、超時重傳會把慢啟動窗口置1MSS 快重傳增長更快

29.滑動窗口的作用？

答：

為重傳（超時重傳，快重傳）提供底層支持，保存舊數據

實現流量控制 動態調整發送量，避免對方過載，提高效率

結合確認應答? 保證可靠性

允許連續發送多個數據，提高效率

30.流量控制和擁塞控制的步驟？

答：

流量控制 避免發送過快 對面接收過慢

在三次握手期間交換互相的窗口大小 （16位窗口大小）

擁塞控制 防止發送過快 大面積丟包

慢啟動 擁塞避免 快重傳 快恢復

31.半連接隊列和全連接隊列？

答：

32.TCP keepalive 和 HTTP keepalive的區別？

答：

TCP keepalive 是在傳輸層定時發送心跳包探測，清理空閑連接

HTTP keepalive 是應用層通過HTTP頭部復用同一個TCP連接進行多次請求處理，減少握手開銷

33.TCP和UDP可以共用一個端口號嗎？

答：

可以，五元組 四元組不同就行

34.如何在UDP實現可靠傳輸

答：

確認+重傳 發送一段時間就停下，啟動定時器，收到ACK才繼續，超時重傳

滑動窗口 允許等待確認前連續發送多個數據

流量控制 擁塞控制

35.SYN報文什么情況會被丟棄？

答：

非監聽狀態、半連接隊列滿了、報文非法、防火墻攔截

有時伴隨著回復RST

36.TCP的主要缺陷？

答：

連接開銷大、擁塞控制過于保守（可能短時間內無法充分發揮帶寬，觸發重傳后置1）、頭部阻塞（如果之前數據丟失，需要先把之前數據發送過去才能處理后面的）、小包延遲與Nagle/Ack延遲沖突（Nagle算法是攢一些再發，延遲ACK是等會再發，可能導致阻塞，延遲高）

36.TCP如何優化？

答：

改進握手/揮手 客戶端第一次握手后下次連接可在SYN中攜帶應用數據，服務器收到直接響應

37.講講擁塞控制？

答：

簡稱cwnd

限制可發送數據量

動態調整發送速率 防止網絡阻塞 大量丟包

TCP滑動窗口中的發送窗口是 對面可接受窗口大小和擁塞窗口的最小值

核心：慢啟動 擁塞避免 快重傳 快恢復

慢啟動：三次握手后，每收到一個ACK增大一點 前期指數 后期線性 快速探測帶寬

擁塞避免：指數增長到閾值改為線性增長

當超時重傳或者快重傳發生

超時重傳：嚴重擁塞 直接慢啟動窗口砍一半 然后重新進入慢啟動階段

快重傳：收到3個重復ACK 輕微擁塞 也砍一半 不過進入快速恢復階段 收到重復ACK線性增長 收到新ACK 回復原大小

優點：動態調整速率 避免丟包

快速恢復

缺點：在高寬帶的情況下不好，例如網絡寬帶超級高 擁塞窗口需要很長時間才能填滿帶寬 帶寬利用率下降

丟包就下調窗口，但是可能丟包不是因為網絡問題

慢啟動代價高，丟包重傳需要重新從1MSS開始

擁塞窗口大小初始一個MSS 增長單位是MSS

38.快重傳如何做到的？對面如何提前知道丟包了？

答：

根據序列號！收到一個序列號不是連續的 就知道這個序列號前面的丟了，然后發送 之前收到的序列號的ACK 告訴對方需要從那里重新發

對面通過ACK來確認是否收到，但是如果三次同一的ACK代表需要重傳了