三次握手（three-way handshake）主要作用就是為了確認雙方的接收能力和傳送能力正常。其實就是連線伺服器指定埠，建立tcp連線，並同步連線雙方的序列號和確認號，交換tcp視窗大小資訊，為後面的可靠性傳送做準備。q1：為什麼兩次握手不可以？(a客戶端，b伺服器)剛開始客戶端處於 closed 的狀態，服務端處於 listen 狀態。
為了防止已經失效的連線請求報文段突然又傳送到了 b，因而產生錯誤。比如：a 發出的第乙個連線請求報文段在網路結點上延誤到之後的連線釋放以後的某個時間段才到達 b。 b 收到此失效的請求報文段後，就誤認為 a 又發出一次新的連線請求。如果不進行第三次握手，b 發出確認後就進入了新的運輸連線狀態，一直等待 a 發來資料。
q2：接收端收到 客戶端的 syn 後，為什麼還要傳回 syn？
接收端傳回傳送端所傳送的 syn 是告訴客戶端接收到的資訊確實是客戶端所傳送的訊號了。
syn 是 tcp / ip 建立連線時使用的握手訊號。在客戶機和伺服器之間建立正常的 tcp 網路連線時，客戶機首先發出乙個
q3：傳了 syn，為什麼還要傳 ack？
傳了 syn，證明傳送方到接收方的通道沒有問題，但是接收方到傳送方的通道還需要 ack 訊號來進行驗證。
q4：為什麼 time-wait 狀態必須等待 2msl 的時間呢？（msl：最長報文段壽命）
tcp釋放連線時為什麼time_wait狀態必須等待2msl時間
1.如果 接收端a 在 time-wait 狀態不等待一段時間，那麼就無法收到 b 重傳的 fin + ack 報文段，因而也不會再傳送一次確認報文段，這樣，b 就無法按照正常步驟進入 closed 狀態。
2. 防止已失效的連線請求報文段出現在本連線中。a 在傳送完最後乙個 ack 報文段後，再經過時間 2msl，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。下乙個連線中不會出現舊的連線請求報文段。
q5：為什麼第二次跟第三次不能合併, 第二次和第三次之間的等待是什麼?
當伺服器執行第二次揮手之後, 客戶端不會再向服務端請求任何資料, 但是服務端可能還正在給客戶端傳送數上一次請求的資源，所以服務端會等到把之前未傳輸完的資料傳輸完畢之後再傳送關閉請求。
q6：tcp 協議是如何保證可靠傳輸的？
資料報校驗：檢測資料在傳輸過程中若出錯，則丟棄報文段並且不給響應， tcp 傳送資料端超時後會重發資料；
對失序資料報重排序：既然 ip 資料報的到達可能會失序，tcp 報文段作為 ip 資料報來傳輸，到達也可能會失序。tcp 將失序重排，然後才交給應用層；
能夠丟棄重複資料；
應答機制：收到發自 tcp 連線另一端的資料，將傳送乙個確認標誌ack。
超時重發：當 tcp 發出乙個段後，就會啟動乙個定時器，設定時間內沒有收到ack將重發這個報文段；
流量控制：tcp 連線的雙方都有固定大小的緩衝空間。不允許對方傳送超過自己緩衝區容量的資料，以防較快主機致使較慢主機的緩衝區溢位。tcp 使用的流量控制協議是可變大小的滑動視窗協議。
q7：tcp握手成功後，如果一方宕機，沒有主動請求關閉，連線會一直儲存麼？
當tcp連線發生一些物理上的意外情況時，例如網線斷開，linux上的tcp實現會依然認為該連線有效，而windows則會在一定時間後返回錯誤資訊。可以通過設定so_keepalive選項來解決，不過不知道這個選項是否對於所有平台都有效。
連線斷開過程-----四次揮手
centos7 中tcp連線問題
新作的centos 7 系統,暫時打算先搭建個ftp和svn伺服器來用.各種配置都搞好了,就是通過區域網的客戶端無法連線,無論是ftp的21埠還是svn的3690全部超時.後來發現putty的ssh協議沒問題,於是懷疑是tcp出問題了.終於在這個帖子裡找到了解決辦法 就是tcp的時間戳導致建立連線時...
20200422 計算機網路 TCP小問
tcp提供可靠的輸出，udp不能提供 tcp面向位元組流，udp面向報文 tcp傳送資料慢，因為需要連線 udp傳輸快。client向server端傳送請求，此時syn 1，狀態變成syn sent server端接受，並且傳送ack 1，狀態程式設計syn rcvd client再向server傳...
jedis 連線centos7需要注意的問題
1 修改redis目錄下的redis.conf配置檔案 如果未設定redis認證密碼，則需要設定保護模式為no protected mode no 2 停止centos7防火牆或設定規則 systemctl stop firewalld 關閉防火牆 systemctl disable firewal...