TCP的原理，作為一個應用開發者來說，可能在平常開發中，99%時間用不上，因為平常用得網路框架比如OkHttp等都已經幫我們封裝好，我們不需要知道里面的原理直接用介面即可，很簡單，
但是作為一個優秀的開發者，我們必須要知其然也需要知其所以然，而且特別在面試的時候， TCP握手和揮手原理經常被問到，如果答得上來，容易加分....
閑話少說，直接上原理圖
【三次握手】
具體流程：
1：客戶端（Client）嘗試請求連接，會隨機產生一個數Sequence碼 X，發給服務端（Server）
2：服務端拿到了客戶端發過來的 Sequence碼 X ，會 將 X + 1 生成 ACK碼，然后自己也會隨機產生一個數Sequence碼Y
然后把ACK 和 Y 一同打包發給 客戶端
3：客戶端拿到客戶端反饋的 ACK 和 Sequence碼，先驗證 ACK 是否在 X 加了1，是就代表服務端反饋的就是自己之前的請求，
然后再把 Sequence碼Y 加 1，生成ACK碼，把 ACK碼回傳給服務端，
（同理服務端也會驗證 回傳的ACK碼是否在Sequence碼Y基礎上加了1 ）
至此，握手通訊成功，可以傳遞資料...
疑問1：為什么傳遞資料前要3次握手通訊，而不是直接傳遞資料呢？？？？？？
因為要保證連接的有效性，避免資源浪費，試想客戶端發了連接請求給服務端，由于網路擁擠等例外原因，請求遲遲發送不到服務端，這時客戶端收不到反饋資料，早下線掉線了，過了幾個小時服務端才收到請求，如果這時不握手驗證，直接就把資料回傳過去，這就造成資源的浪費，如果在資料傳遞前驗證握手通訊，即可保證雙方都“在線”，也可以保證 請求-回傳 是一一對應的，
【四次揮手】
具體流程：
1：客戶端嘗試斷開連接，會發送斷開TCP連接請求的報文，會將FIN置1，并會隨機產生 Sequence碼 M，發給我 服務端
2：服務端收到 TCP連接請求報文，會將M+1 生成 ACK碼，回傳給客戶端，客戶端接收到自己的 Sequence碼 加了1，說明斷開 請求已經得到驗證，
3：服務端在收到斷開TCP連接請求的報文，并不會立馬斷開連接，而是等自己的資料全部都發送出去才會斷開連接，所以服務端在保證已經把所有資料發送出去之后，把FIN置1，產生隨機產生Sequence碼N，把N發送給客戶端，
4：客戶端收到服務端的請求斷開報文，會把 N+1 生成ACK，反饋給服務端，服務端校驗到ACK是在Sequence碼N加了1，從而完成服務端請求的驗證回復，
至此，4次揮手完成，
疑問2：斷開前要4次揮手，而不是直接斷開連接呢？？？
因為 TCP連接是全雙工的，一方需要斷開，得另一方確認，這樣一來一回就是四次通訊了，再者這么設計，也是為了保證資料傳輸的完整性，因為C發送了斷開報文，僅僅代表C沒有了資料傳遞過來，C還能接受資料，如果S接收到斷開報文就立馬斷開，假如此時還有剩余資料沒有傳輸完呢？這樣直接斷開就會造成資料傳遞丟失了，所以服務端會先同意客戶端的斷開請求，再確保服務端自己已經把全部資料發送完，再發送斷開報文給客戶端，所以步驟2和3一般是分開來發送的，所以這樣一來一回的揮手，就是4次揮手了，
疑問3：4次揮手，能不能改成3次揮手？
可以！只要服務端在收到斷開報文時，已經確保了所有資料已經發送完了，這樣步驟2和3可以合在一起發送，這樣就是三次揮手了，不過，一般會分開來發送的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/168390.html
標籤：其他