當客戶端發送的請求因為網路問題而導致資料包序號無法對上時，會觸發TCP的重傳機制。那么之前所發送的資料包是否會被服務端收到，并為客戶端創建半連接？求問，感謝大佬
uj5u.com熱心網友回復：
連接是重傳前就建立好的吧，跟重傳沒什么關系，重傳是連接建立成功之后發生的事情。重傳之前發送的資料包當然有可能被服務端收到，但是重傳后因為序號是跟之前的一樣的，重傳的包會被協議丟棄。uj5u.com熱心網友回復：
那在TCP第一次握手時，發送建立連接的請求也是以資料包的形式進行的吧。那當發送的請求資料包序號因為客戶端的網路問題而無法與之后的資料包序號對上，且客戶端因為網路問題而無法重新發送請求。那這種情況下，按你的說法是，服務端已經收到部分資料包，并會為這個資料不完整的請求建立連接？還是說，服務端因為構成請求的資料不完整而不會為客戶端建立半連接呢？求問，??uj5u.com熱心網友回復：
我覺得可以看成兩個階段。第一個階段是建立連接，如果中間三次握手失敗，那就無所謂后續的發送資料包了，資料傳輸是在連接建立成功后才開始的。比如第一次握手的包發成功了，但是沒有收到另一端回傳的包，那連接就沒建立成功。第二個階段是雙方的資料互動，中間有超時重傳等機制。uj5u.com熱心網友回復：
可是為什么我聽說好像是服務端收到請求之后，會為客戶端創建半連接。當服務端收到第三次握手時，為客戶端建立完全的連接。（我指的半連接是服務端為客戶端創建了執行緒，或者說是做了一些建立完全連接前的準備作業）還有我想知道的是第一次握手時，客戶端發送的請求是以一個個資料包的形式進行發送的吧（即一個請求由許多資料包組成）。那么在沒有建立連接之前，服務端因為客戶端的網路問題而只收到了不完整的請求。最終服務端會為這個不完整的請求創建半連接呢？還是不會呢？
請原諒我知識的淺薄
uj5u.com熱心網友回復：
我理解的是這樣的：三次握手不成功的話，服務端不會為客戶端建立連接，當然也就不會創建處理執行緒了。半連接這個，我也是第一次聽說，好像沒有這個東西吧，要么建立連接，開始資料互動；要么連接連接不成功，無法進行后續資料互動。uj5u.com熱心網友回復：
推薦一本書，《計算機網路：自頂向下》，tcp那一章解釋地挺通俗易懂的。uj5u.com熱心網友回復：
好的，感謝解答，謝謝??uj5u.com熱心網友回復：
樓主說從哪里得到這些資訊的？恐怕是被誤導了。半連接僅存在于單方面關閉連接的時候，比方服務器收到一個請求，它不再需要接受客戶端的后續請求了，就可以單方面關閉客戶端的半連接，對應的API就是shutdown：但此時它還可以繼續發資料給客戶端，然后會在發完所有資料之后再發一個FIN結束本次會話。uj5u.com熱心網友回復：
不存在連接不完整建立的半連接，在三路握手中，只要有一次資料不完整，在超時的情況下，連接就會被判定為失敗。第一次握手，如果沒收到回應就會超時重發，直到最大超時就認為失敗；服務器確認連接如果沒收到回應也是一樣。如果兩邊不能保持一致狀態，比方客戶端認為是連接的，但服務器這邊沒收到多少次握手信號，這時候對于客戶端的請求，服務器會用一個復位來回應，客戶端收到復位回應就會重置這個連接，這時候就可以準備重新開始連接了uj5u.com熱心網友回復：
會創建半連接, 這個就是tcp攻擊的一種方式. 監聽函式的引數 好像就是半連接 和全連接的數量uj5u.com熱心網友回復：
比如 客戶端大量發送第一次握手的請求,并且不發送第二次握手的回復,那么服務器端將會產生大量的等待三次握手的資料,直到服務器崩潰.所以服務器藥配置合適的等待tcp三次握手的數量
uj5u.com熱心網友回復：
那么請問下，如果在發送建立連接的請求程序中，如果客戶端因為網路問題而導致發送的請求不完整，例如：由于請求是由一個個資料包構成的，那么由于服務端收到的資料包不完整，服務端是否會因為收到不完整的請求而為客戶端建立半連接呢？還是不會呢？感謝??uj5u.com熱心網友回復：
無論哪一方有網路例外，只能是斷開重連（例外方斷開就可以了）。
TCP本身沒有例外重發資料機制，例外重發只會引起協議混亂
uj5u.com熱心網友回復：
如果你想知道 TCP 的作業原理，網上找點文章讀一下。當然網上的文章胡說的也不少。所以還是推薦你買一本講TCP的書。如果你只是想知道如何對 TCP 做應用編程，那就不用管你的這些問題。這些問題是 TCP 協議堆疊幫你搞定的，你無需管它。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/12725.html
標籤：網絡通信/分布式開發
上一篇：ITK-SNAP label保存