⑴ TCP連接建立過程中為什麼需要「三次握手」
傳輸控制協議 TCP）是一種面向連接的、可靠的、基於位元組流的運輸層（Transport layer）通信協議。是專門為了在不可靠的互聯網路上提供一個可靠的端到端位元組流而設計的。互聯網路與單個網路不同，因為互聯網路的不同部分可能有著截然不同的拓撲、帶寬、延遲、分組大小和其他參數。TCP的設計目標是能夠動態的適應互聯網路的這些特性，而且當面對多種失敗的時候仍然能夠健壯。 每一次TCP連接都需要三個階段：連接建立、數據傳送和連接釋放。三次握手就發生在連接建立階段。 在謝希仁著《計算機網路》第四版中講三次握手的目的是 為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。在另一部經典的《計算機網路》一書中講三次握手的目的是為了解決 網路中存在延遲的重復分組的問題。 這兩種不用的表述其實闡明的是同一個問題。 謝希仁版《計算機網路》中的例子是這樣的，已失效的連接請求報文段的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用三次握手，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用三次握手的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。 這個例子很清晰的闡釋了三次握手對於建立可靠連接的意義。 在Google Groups的 TopLanguage 中看到一帖討論TCP三次握手覺得很有意思。貼主提出 的問題，在眾多回復中，有一條回復寫道：這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什麼信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是為了滿足"在不可靠信道上可靠地傳輸信息"這一需求所導致的. 請注意這里的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接著握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就沒關系了. 因此,如果信道是可靠的, 即無論什麼時候發出消息, 對方一定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就可以了. 。這可視為對三次握手目的的另一種解答思路。
⑵ 三次握手機制用於解決什麼
用於解決網路中出現重復請求報文的問題。
第一次：首先A發送一個(SYN)到B，意思是A要和B建立連接進行通信，如果是只有一次握手，這樣肯定是不行的，A壓根都不知道B是不是收到了這個請求。
第二次：B收到A要建立連接的請求之後，發送一個確認(SYN+ACK)給A，意思是收到A的消息了，B這里也是通的，表示可以建立連接。如果只有兩次通信，這時候B不確定A是否收到了確認消息，有可能這個確認消息由於某些原因丟了。
第三次：A如果收到了B的確認消息之後，再發出一個確認(ACK)消息，意思是告訴B，這邊是通的，然後A和B就可以建立連接相互通信了。
(2)計算機網路中三次握手用於擴展閱讀：
注意事項：
剛接觸網路編程時，感覺網路連接的建立、網路數據的收發、網路連接的斷開這些操作僅僅是調用幾個socket AIP就可以搞定的事情，跟網路中講述的TCP三次握手等內容完全扯不上關系。
listen函數：內核為任何一個給定的套接字維護兩個隊列 1.未完成連接狀態（客戶端發送的第一個SYN已經到伺服器，伺服器等待TCP三次握手完成，這些套接字處於SYN_RCVD狀態）。
⑶ 一文搞定 UDP 和 TCP 高頻面試題！
在求職面試中，UDP和TCP是常被問到的計算機網路概念。無論春招秋招，面試官幾乎都會涉及這些問題，尤其在作者參加的50場面試中，幾乎每輪都有涉及。了解這些問題不僅能提升面試自信，還能給面試官留下深刻印象。本文將總結常見的面試問題，幫助你應對相關知識點。
- UDP和TCP特點：UDP是無連接、盡力而為、不保證順序，支持多對多通信，而TCP是面向連接、可靠傳輸、有流量控制和擁塞控制，一對一通信。
- 首部格式：UDP只有8位元組，包括源埠、目的埠等；TCP首部復雜，包含序號、確認號、窗口值等控制位，用於保證數據完整性和可靠性。
- 三次握手：TCP建立連接，防止連接請求失效，確認雙方接收和發送能力正常。
- 四次揮手：關閉連接，確保數據傳輸完成，服務端等待所有數據發送完再發送FIN，客戶端等待伺服器確認關閉。
- 短連接與長連接：短連接是一次操作就斷開，長連接可多次數據交換，管理復雜但可復用連接。
- 粘包和拆包：TCP基於位元組流，可能導致數據包重組，需要通過應用層協議處理。
- 可靠傳輸與流量控制：TCP通過超時重傳和滑動窗口機制確保數據完整，流量控制防止接收方過載。
掌握這些核心知識點，面試時就能從容應對，展現你的專業知識。最後，不要忘了實踐和復習，讓知識真正運用到實際中。
⑷ 計算機網路經典20問
本文目錄 ：
計算機網路體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。
TCP/IP五層模型：應用層、傳輸層、網路層、數據鏈路層、物理層。
假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是 CLOSED 。
第三次握手主要為了 防止已失效的連接請求報文段 突然又傳輸到了服務端，導致產生問題。
因為當Server端收到Client端的 SYN 連接請求報文後，可以直接發送 SYN+ACK 報文。 但是在關閉連接時，當Server端收到Client端發出的連接釋放報文時，很可能並不會立即關閉SOCKET ，所以Server端先回復一個 ACK 報文，告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發送完了，這時Server端才能發送連接釋放報文，之後兩邊才會真正的斷開連接。故需要四次揮手。
HTTP請求由 請求行、請求頭部、空行和請求體 四個部分組成。
請求報文示例 ：
HTTP響應也由四個部分組成，分別是： 狀態行、響應頭、空行和響應體 。
響應報文示例 ：
HTTP2.0相比HTTP1.1支持的特性：
服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容： 證書內容、證書簽名演算法和簽名 ，簽名是為了驗證身份。
服務端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應本網站。
數字簽名的製作過程 ：
瀏覽器驗證過程 ：
首先是TCP三次握手，然後客戶端發起一個HTTPS連接建立請求，客戶端先發一個 Client Hello 的包，然後服務端響應 Server Hello ，接著再給客戶端發送它的證書，然後雙方經過密鑰交換，最後使用交換的密鑰加解密數據。
對稱加密 ：通信雙方使用 相同的密鑰 進行加密。特點是加密速度快，但是缺點是密鑰泄露會導緻密文數據被破解。常見的對稱加密有 AES 和 DES 演算法。
非對稱加密 ：它需要生成兩個密鑰， 公鑰和私鑰 。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密演算法 安全性更高 ，但是 計算量相比對稱加密大很多 ，加密和解密都很慢。常見的非對稱演算法有 RSA 和 DSA 。
⑸ 計算機網路中的「三次握手」是什麼
TCP握手協議
在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。
第一次握手：建立連接時，客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
SYN：同步序列編號(SynchronizeSequenceNumbers)
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
完成三次握手，客戶端與伺服器開始傳送數據，在上述過程中，還有一些重要的概念：
未連接隊列：在三次握手協議中，伺服器維護一個未連接隊列，該隊列為每個客戶端的SYN包（syn=j）開設一個條目，該條目表明伺服器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在伺服器處於Syn_RECV狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器進入ESTABLISHED狀態。
Backlog參數：表示未連接隊列的最大容納數目。
SYN-ACK重傳次數伺服器發送完SYN－ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同。
半連接存活時間：是指半連接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時我們也稱半連接存活時間為Timeout時間、SYN_RECV存活時間。