❶ tcp連接建立和斷開過程
tcp的建立必須有一方主動，舉個通俗的例子 ：男孩客戶端，女孩服務端，用他們之間的交往說明三次握手的過程
1、男孩喜歡女孩，寫了一封信告訴女孩：你長得漂亮，我稀罕你！寫完信之後，男孩焦急地等待，因為不知道信能否順利傳達給女孩。SYN=1，seq=X
2、女孩收到男孩的情書後，心花怒放，於是回信：我收到你的情書了，其實，我也喜歡你！我願意和你交往！;寫完信之後，女孩也焦急地等待，因為不知道回信能否能順利傳達給男孩。SYN=1，ack=x+1,seq=y
3、男孩收到回信之後很開心，因為發出的情書女孩收到了，並且從回信中知道了女孩喜歡自己，並且願意和自己交往。然後男孩又寫了一封信告訴女孩：你的心意和信我都收到了，謝謝你，還有我愛你 SYN=1,ack=Y+1,seq=X+1
彼此都收到回信，大家開心交流了起來。這就是通俗版的「三次握手」，期間一共往來了三封信也就是「三次握手」，以此確認兩個方向上的數據傳輸通道是否正常。
tcp斷開，也是有一方主動，也用這個例子。
"第一次揮手"：男：你太懶了，我要和你分手 FIN=1,seq=x
「第二次揮手」：女：好，臭男人，等我把我的東西收拾完 FIN=1，ack=X+1,seq=y
男孩收到女孩的第一封信之後，明白了女孩知道自己要和她分手。隨後等待女孩把自己的東西收拾好。
「第三次揮手」：過了幾天，女孩把男孩送的東西都整理好了，女：臭男人，我的東西收拾完了，咱們分手吧！FIN=1，ack=X+1,seq=z
「第四次揮手」：男：好，拜拜！ FIN=1，ack=z+1,seq=h
當然這里雙方都有各自的堅持。女孩自發出第二封信開始，限定一天內收不到男孩回信，就會再發一封信催促男孩來取東西！男孩自發出第二封信開始，限定兩天內沒有再次收到女孩的信就認為，女孩收到了自己的第二封信；若兩天內再次收到女孩的來信，就認為自己的第二封信女孩沒收到，需要再寫一封信，再等兩天…..
倘若雙方信都能正常收到，最少只用四封信就能徹底分手！這就是「四次揮手」。
❷ 簡述TCP連接建立與斷開的過程
TCP 是一個面向連接的協議，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一條連接。本節將詳細討論一個TCP 連接是如何建立的以及通信結束後是如何終止的。
建立一個 TCP 連接
TCP使用三次握手 （ three-way handshake ） 協議來建立連接，圖 3-10 描述了三次握手的報文序列。這三次握手為：
請求端（通常稱為客戶）發送一個 SYN 報文段（ SYN 為 1 ）指明客戶打算連接的伺服器的埠，以及初始順序號（ ISN ）。
伺服器發回包含伺服器的初始順序號的 SYN 報文段（ SYN 為 1 ）作為應答。同時，將確認號設置為客戶的 ISN 加 1 以對客戶的 SYN 報文段進行確認（ ACK 也為 1 ）。
客戶必須將確認號設置為伺服器的 ISN 加 1 以對伺服器的 SYN 報文段進行確認（ ACK 為 1 ），該報文通知目的主機雙方已完成連接建立。
發送第一個 SYN 的一端將執行主動打開（ active open ），接收這個 SYN 並發回下一個 SYN 的另一端執行被動打開（ passive open ）。另外， TCP 的握手協議被精心設計為可以處理同時打開（ simultaneous open ），對於同時打開它僅建立一條連接而不是兩條連接。因此，連接可以由任一方或雙方發起，一旦連接建立，數據就可以雙向對等地流動，而沒有所謂的主從關系。
三次握手協議是連接兩端正確同步的充要條件。因為 TCP 建立在不可靠的分組傳輸服務之上，報文可能丟失、延遲、重復和亂序，因此協議必須使用超時和重傳機制。如果重傳的連接請求和原先的連接請求在連接正在建立時到達，或者當一個連接已經建立、使用和結束之後，某個延遲的連接請求才到達，就會出現問題。採用三次握手協議（加上這樣的規則：在連接建立之後 TCP 就不再理睬又一次的連接請求）就可以解決這些問題。
三次握手協議可以完成兩個重要功能：它確保連接雙方做好傳輸准備，並使雙方統一了初始順序號。初始順序號是在握手期間傳輸順序號並獲得確認：當一端為建立連接而發送它的 SYN 時，它為連接選擇一個初始順序號；每個報文段都包括了順序號欄位和確認號欄位，這使得兩台機器僅僅使用三個握手報文就能協商好各自的數據流的順序號。一般來說， ISN 隨時間而變化，因此每個連接都將具有不同的 ISN 。
關閉一個 TCP 連接
TCP 連接建立起來後，就可以在兩個方向傳送數據流。當 TCP 的應用進程再沒有數據需要發送時，就發關閉命令。 TCP 通過發送控制位 FIN=1 的數據片來關閉本方數據流，但還可以繼續接收數據，直到對方關閉那個方向的數據流，連接就關閉。
TCP 協議使用修改的三次握手協議來關閉連接， 如圖 3-11 所示，即終止一個連接要經過 4 次握手。這是因為 TCP 的半關閉（ half-close ）造成的。由於一個 TCP 連接是全雙工（即數據在兩個方向上能同時傳遞），因此每個方向必須單獨地進行關閉。關閉的原則就是當一方完成它的數據發送任務後就能發送一個 FIN 來終止這個方向連接。當一端收到一個 FIN ，它必須通知應用層另一端已經終止了那個方向的數據傳送。發送 FIN 通常是應用層進行關閉的結果。
❸ 怎樣強制斷開TCP連接
TCP通信的話，服務端斷開時會自動通知客戶端客戶端處理該事件就可以了
❹ tcp連接的斷開
TCP的斷開就是經過四次揮手：
這是正常的情況，客戶端主動tcp連接斷開的過程。客戶端先是發送一個FIN為一的報文，然後進入FIN_WAIT_1的狀態。
伺服器收到FIN報文後，發送一個ACK報文，然後進入CLOSED_WAIT狀態。
客戶端收到伺服器的ACK報文進入FIN_WAIT_2狀態。
等到伺服器覺得他數據處理好了，可以關閉的時候，會發送一個FIN報文，然後進入LAST_ACK。等待最後一個應答。
讓客戶端收到伺服器FIN報文，就進入TIME_WAIT狀態了，隨後發送最後一個ACK報文，然後close。
客戶端再等待2msl後也自己主動關閉。而只有主動關閉的情況下，才會有TIME_WAIT。
那麼為什麼四次揮手需要四次呢？
三次握手其實就是在第二次把ACK和SYN兩個報文合並成一個發，但是斷開的過程可能還有一方需要處理下數據，需要延長點時間，等處理好再發FIN，所以就比三次握手多了一次。
這里還有一個問題，為什麼需要TIME_WAIT，然後到close需要2msl的時間呢？
先說下什麼是MSL，也就是報文的最長生存時間，超過這個時間的報文就要被丟棄掉。tcp是基於ip的，ip上有個生存時間TTL,是ip報文可以經過的最大路由數量，每經過一個路由就減1，減到0，ip報文就丟棄掉，然後通過ICMP通知源主機，我們的ping也算是經過這個。當然msl和ttl還是有區別的，msl是時間，ttl是路由數量，msl也是大於等於ttl的。在linux中，2msl默認是60秒。
前文也說了，只有主動發起斷開連接的進程才會有time wait狀態。time wait+2msl有兩個原因：
1.防止舊連接的數據包
像這個seq 301的包，如果因為網路的原因被延遲了，而沒有time wait或者很短，那麼連接斷開後，又建立新的連接，這個時候這個包到了，可能就導致數據紊亂了。而2msl可以保證兩個方向的包在斷開前丟棄掉。
2.保證正確的斷開連接
2msl的時間也是保證第四個報文的ack可以被被動關閉方接收到。
如圖，假設time wait比較短或者沒有，當最後的ack報文丟失的時候。客戶端已經close了，而伺服器一直處於last ack的狀態。這樣連接就不能正常斷開了。而如果有time wait +2msl這個情況就可以避免。假設伺服器沒有收到最後一個ack報文，伺服器會重發FIN等待客戶端的ack。
這樣就可以保證不會出現一端斷開，另外一端沒有斷開的情況了。
有時候我們在伺服器上會看到很多time wait。time wait一般就是伺服器主動發起的斷開請求才會產生的狀態。所以time wait過多，第一個是系統資源會大量消耗，還有是埠如果占的太多，會導致沒辦法創建新連接。這個時候可以把linux的net.ipv4.tcp_tw_reuse開啟，置為1，可以復用time wait超過1秒的連接。
這邊再說說tcp的保活機制。也就是怎麼長期維持客戶端和服務端的連接。
在一個時間段內，如果沒有連接等相關活動，tcp的保活機制會定期發探測報文，如果連續幾個探測報文就沒有回應，就將錯誤信息報告給系統，系統通知上層應用。
在 Linux 內核可以有對應的參數可以設置保活時間、保活探測的次數、保活探測的時間間隔，以下都為
默認值：
tcp_keepalive_time=7200：表示保活時間是 7200 秒（2⼩時），也就 2 小時內如果沒有任何連接
相關的活動，則會啟動保活機制
tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒；
tcp_keepalive_probes=9：表示檢測 9 次無響應，認為對⽅方是不不可達的，從⽽而中斷本次的連接。
也就是說在 Linux 系統中，最少需要經過 2 小時 11 分 15 秒才可以發現一個「死亡」連接。
當然這個時間也可以自己配置。
❺ 求教tcp短連接斷開後如何重連的問題
理想狀態下，一個 TCP 連接可以被長期保持。然而，在實際應用中，客戶端或伺服器端上維持的一個看似正常的 TCP 連接可能已經斷連。TCP 連接主要受到兩個方面的影響而導致斷連：網路中間節點和客戶端 / 伺服器節點參與通信的兩方節點？
在
實際網路應用中，兩個主機之間的通信往往需要穿越多個中間節點，例如路由器、網關、防火牆等。因此，兩個主機之間 TCP
連接的保持同樣會受到中間節點的影響，尤其是會受到防火牆（軟體或硬體防火牆）的限制。防火牆是一種裝置，有多種不同的實現方式（軟體實現、硬體設備實現
或是軟硬體相結合實現），它需要依據一系列規則對進出的信息流進行掃描，並允許安全（符合規則）的信息交互、阻止不安全（違反規則）的信息交互。防火牆的
工作特性決定了要維護一個網路連接就需要耗費較多的資源，並且企業防火牆常常位於企業網路的出入口，長時間維護非活躍的 TCP
連接必將導致網路性能的下降。因此，大部分防火牆默認會關閉長時間處於非活躍狀態的連接而導致 TCP
連接斷連。類似的，如果中間節點異常導致來自客戶端關閉連接的請求無法傳遞到伺服器端，也將導致伺服器端的相應連接發生斷連。
❻ TCP/IP斷開
伺服器重啟後，客戶端處於半打開狀態，也就是FIN-WAIT-1狀態。客戶端覺得連接還是正常的，但是服務端丟失了連接的所有信息。這種情況下，客戶端發送請求給服務端，服務端無法處理，就會出現超時。當然，客戶端會嘗試重新發送，但是重試次數是有限的，重試次數由tcp_orphan_retries參數控制。經過幾輪重試後，如果一直沒有收到服務端的ACK，就會關閉連接。
由於FIN-WAIT-1狀態是服務端主動斷開客戶端的連接導致的，此時可以減小重試次數，盡快讓客戶端請求超時，超時後連接會自動關閉。
❼ TCP連接相關
為什麼要有三次握手，因為如果只有兩次握手，那麼
第一次：客戶端發送一個syn包給伺服器，裡面有一個隨機生成的syn，然後客戶端處於syn_send狀態
第二次：服務端收到客戶端發來的syn包之後，確認syn包，也就是生成一個ack=syn+1，然後再自己隨機生成一個syn包，即syn+ack包，然後返回給客戶端，自己變成syn_recv狀態
第三次：客戶端收到服務端發來的syn+ack包之後，確認ack是正確的之後，返回一個ack=syn+1給服務端，此包發送完畢，客戶端進入了ESTABLISHED狀態，服務端收到ack包後也進入ESTABLISHED狀態。
SYN攻擊，當第二次握手服務端發送了syn+ack包之後，收到客戶端發送的ack之前這段時間的tcp鏈接成為半連接，此時服務端處於syn_recv狀態。當大量客戶端隨機IP瘋狂發送tcp鏈接請求時，客戶端以為是不同用戶的請求，所以隊列中全是半連接，然後導致伺服器宕機，正常請求被丟棄。
第一個包發送過程丟失
A會周期性超時重傳，直到收到B的確認
第二個包發送過程丟失
B會周期性超時重傳，直到收到A的確認
第三個包發送過程丟失
A發送完數據後單方面進入TCP的ESTABLISHED狀態，B還處於半鏈接：
TCP協議為什麼需要三次握手？
第一次：客戶端發送一個fin給服務端表示自己要斷開連接了，然後進入fin_wait_1狀態
第二次：服務端收到fin後，發送一個ack=fin+1給客戶端，服務端進入close_wait狀態，客戶端進入fin_wait_2狀態
第三次：服務端發送一個fin，用來關閉服務端到客戶端的數據傳輸，服務端進入last_ack狀態
第四次：客戶端收到fin後，進入time_wait狀態，然後發送一個ack=fin+1給服務端，服務端確認後進入close狀態，完成四次揮手
TCP協議是一種面向連接的、可靠的、基於位元組流的運輸層通信協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態變化。
答案解析：
瀏覽器對並發請求的數目限制是針對域名的，即針對同一域名（包括二級域名）在同一時間支持的並發請求數量的限制。如果請求數目超出限制，則會阻塞。因此，網站中對一些靜態資源，使用不同的一級域名，可以提升瀏覽器並行請求的數目，加速界面資源的獲取速度。
在 HTTP/1.0 中，一個http請求收到伺服器響應後，會斷開對應的TCP連接。這樣每次請求，都需要重新建立TCP連接，這樣一直重復建立和斷開的過程，比較耗時。所以為了充分利用TCP連接，可以設置頭欄位 Connection: keep-alive ，這樣http請求完成後，就不會斷開當前的TCP連接，後續的http請求可以使用當前TCP連接進行通信。
第一次訪問有初始化連接和SSL開銷
初始化連接和SSL開銷消失了，說明使用的是同一個TCP連接。
HTTP/1.1 將 Connection 寫入了標准，默認值為 keep-alive 。除非強制設置為 Connection: close ，才會在請求後斷開TCP連接。
所以這一題的答案就是：默認情況下建立的TCP連接不會斷開，只有在請求頭中設置 Connection: close 才會在請求後關閉TCP連接。
HTTP/1.1 中，單個TCP連接，在同一時間只能處理一個http請求，雖然存在Pipelining技術支持多個請求同時發送，但由於實踐中存在很多問題無法解決，所以瀏覽器默認是關閉，所以可以認為是不支持同時多個請求。
HTTP2 提供了多路傳輸功能，多個http請求，可以同時在同一個TCP連接中進行傳輸。
頁面資源請求時，瀏覽器會同時和伺服器建立多個TCP連接，在同一個TCP連接上順序處理多個HTTP請求。所以瀏覽器的並發性就體現在可以建立多個TCP連接，來支持多個http同時請求。
Chrome瀏覽器最多允許對同一個域名Host建立6個TCP連接，不同的瀏覽器有所區別。
補充
如果圖片都是HTTPS的連接，並且在同一域名下，瀏覽器會先和伺服器協商使用 HTTP2 的 Multiplexing 功能進行多路傳輸，不過未必所有的掛在這個域名下的資源都會使用同一個TCP連接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上實現的），那麼瀏覽器會就在同一個host建立多個TCP連接，每一個TCP連接進行順序請求資源。
參考：
[1]. 第8題-瀏覽器HTTP請求並發數和TCP連接的關系
❽ 正在嘗試寫一個TCP伺服器，為什麼我的客戶端怎樣都連接不上
1）如果是寬頻本身的問題，首先直接聯接寬頻網線測試，如果是寬頻的問題，聯系寬頻客服解決。
2）如果是路由器的問題，如果原來可以用，暫時不能用了，我自己的實踐是一個是斷掉路由器的電源在插上，等會看看。在有就是恢復出廠設置，從新設置就可以用了（這是在物理連接正確的前提下，有時是路由器尋IP地址慢或失敗引起的，並不是說路由器壞了）。
如果總是不能解決，建議給路由器的客服打電話，他們有電話在線指導，我遇到自己不能解決的問題，咨詢他們給的建議是很有用的，他們會針對你的設置或操作給出正確建議的。
3）如果關閉了無線開關開啟就是了，如果是用軟體連接的無線，軟體不好用又經常出問題是很正常的，沒有更好的方法，用路由器吧。另外就是網卡驅動沒有或不合適引起的，網線介面或網線是不是有問題等。
4）如果是系統問題引起的，建議還原系統或重裝。
❾ 為什麼我寫的modbus tcp通信協議伺服器一斷，在起來連不上客戶端
可能是你沒有處理好關閉連接，伺服器程序如果出錯退出，或者退出時沒進行斷開客戶端的操作，會造成客戶端不知道伺服器已停止工作，而繼續保持虛連接，造成重連失效。
建議完善伺服器程序設計，在伺服器退出前，增加關閉所有客戶端連接，並收回socket的操作。
❿ 傳輸層TCP協議連接的建立和斷開
什麼是TCP呢？
由三個單片語成的Transport Control Protocol，字面理解是傳輸控制協議，可以理解為比特同學要想在網路泳池裡游泳，那麼他必須學習傳輸層控制技能，並且要掌握相應的動作——協議，他才能在暢游世界網路這個超大型游泳池。
TCP：一個傳輸層協議，提供Host-To-Host的可靠傳輸，支持全雙工，是一個面向連接的協議。
TCP工作在傳輸層，它的上層是應用層，應用就是人們常用的微信、抖音、王者榮耀等服務工作的協議。兩台不同的設備使用微信聊天，發送語音，需要實現Host-To-Host的數據通信，那麼就可以直接調用TCP協議進行。
調用TCP通信時需要指定通信的埠，不同的埠對應不同應用，不同IP對應不同的主機，也就是不同的設備。這就涉及到網路地址—— IP地址 ，工作在網路層，當然TCP層只負責把對應的IP地址和埠傳給網路層即可，具體業務由網路層來實現。
互聯網層，即Network Layer ，提供地址和地址間的通信，只關注地址到地址Address-To-Address間通信，具體設備間通信由數據鏈路層實現，數據鏈路層關注MAC地址間通信，具體的物理設備，傳輸介質由物理層負責。
以上就是TCP/IP協議常用的層級分割，最終目的就是為Host-To-Host服務，實現應用到應用的通信服務。
什麼是連接和會話呢？
連接事需要通信雙方相互配合來實現的，是雙方達成的一種即時的狀態約定，保證通信雙方都在線，都有能力為接下來的數據傳輸做出盡快的響應，我們稱之為 連接 。
連接是網路行為狀態的記錄，既然連接需要雙方共同努力，那麼就需要雙方都有一個對象來記憶當前傳輸的數據類型，對方的埠、已經傳輸了多少，效率怎麼樣等等一些關注點。
那麼與之相關聯的另一個名詞 會話（Session） ，是什麼意思呢，會話是應用的行為。大家每次用微信聊天時都會有一個窗口，用來發送信息，你來我往，這個窗口中會有很多條信息，我們稱之為會話，當我們在會話進行中，連接一定是在通信狀態的。聊一會，累了，退出微信了，但是一般我們不會刪除我們的會話內容，這時會話還在，但是連接已經中斷。
雙工/單工問題
想想自己理解的是什麼？
單工：任何時間，數據只能單向發送，單工至少需要一條線路
半全雙工：某一時候可以雙向發送數據，至少需要一條線路
全雙工：任何時刻都可以雙向發送數據，大於一條線路
這里線路不一定真實存在物理線路，可能採用模擬的形式實現
TCP是一個全雙工協議，數據任何時刻都可以雙向發送 ，這說明伺服器和客戶端可以根據需要選擇任意時刻發送和接收信息，所以呢都可以被稱為主機（Host）
可靠性的定義
TCP可以提供可靠性，那麼可靠性具體的實現方式是什麼呢？
可靠性指數據無損傳輸 。發送主機按照順序發送數據，數據通過網路傳輸，收不同網路條件限制，數據不會按照發送時的順序到達接收方，這時我們就需要一種演算法來保證接收方可以還原出發送方的順序。這里還有一個概念叫 多播 ，發送方同時發送給多個接收方信息，如果接收方中有一個接收到了這條信息，我們的可靠性就必須保證其他接收方也必須接收到相同的信息，這里我們不討論多播。
TCP的握手和揮手
TCP是一個面向連接的連接的協議， 握手 是建立連接的過程， 揮手 是斷開連接的過程。
TCP的基本操作
以上三種操作以後，另一方必須立即給發起方返回一個 ACK（Ackknowledgement） ，這是TCP保證可靠性的要求。如果一方不回復發送方ACK，發送方則認為接收方沒有收到信息，會重新發送。
建立連接的過程-三次握手
三次握手的形成和TCP要求每次發送方發送信息以後，接收方必須返回ACK確認有直接的關系
上圖描述了TCP建立連接的過程，分為6步：
TCP建立連接的過程如上，那麼為什麼是三次呢？
第二步服務端做准備，因為是首次收到發送數據請求，無需處理，可以立刻進入數據交互狀態，所以可以立刻發送給客戶端SYN，告訴客戶端，我已准備好，所以第三步和第四步可以合並為一次握手——ACK-SYN，然後客戶端回應ACK，連接建立完成
以上就是三次握手了
具體在數據交互過程，ACK和SYN等需要用標識位來標記，在實際應用中，我們一般使用1來表示開啟，0表示關閉。
那麼四次揮手為什麼是四次呢，主要是因為，揮手時服務端收到FIN以後，不能馬上回復FIN，因為自身還有任務沒有處理完，所以上面所說的6步中，第3、4步就不能一起回復，只能先回復ACK，等自身任務處理完畢，才能告訴客戶端，我已經准備好，可以關閉連接，這樣就需要4次數據交互，如下圖：