在網路的傳輸層協議中, 存在著兩大悍將:tcp和udp. 從前, 我傻傻的以為自己對他們雖談不上精通, 但還是知道的, 但是, 我錯了, 我被自己問住了, 我傻了. 啥也不是.
(這裡為了介紹簡單, 就不提資料在傳輸過程中的失真(糾錯碼)等情況了. 簡單介紹一下,tcp才是今天的主角)
udp 就是, 我把資料發給你了, 我不管你有沒有收到, 反正我發出去了, 任性. 就比如我要給我的女神表白, 但是我又不好意思, 所以我托我的好兄弟馬六幫我給女神帶句話, 但是這個馬六也臉皮薄, 他又找週三轉達, 就這樣雖然歷經波折, 但最後還是順利的將話帶到了女神那裡. 在這個過程中我做了什麼? 我只是將訊息送出去了, 僅此而已. 最後我滿心歡喜的等待著女神的回覆, 可能換回一句: 我們還是做朋友吧. 但還有一種可能, 那就是最終根本就沒有送到女神那裡, 中間轉到週三的時候, 他因為自己的事情, 把這事給忘了, 可憐的我還苦苦的等...
udp雖然省事, 高效, 但是卻不可靠. 因為我僅僅是發出去了, 但是我不確定你有沒有收到. 不可靠有什麼問題麼? 上面就是個例子. 再比如, 咱倆聊天, 我給你發了一段話:123456, 結果中間4丟了, 你收到的資訊是:12356. 這種還好, 如果快過年了, 我發給你這樣一段話:明天把你的豬宰了吧, 哎, 中間的豬丟了, 那估計免不了一番腥風血雨.
為了保證傳輸資料的可靠性,tcp誕生了. 還記得剛才我給女神表白的時候, 問題出在**嗎? 沒錯, 就是因為我到最後苦苦等待, 結果她悲劇的沒有收到我的心意, 傷心. 怎麼辦呢? 這次我想通了, 求人不如求己, 我要鼓起勇氣, 我到她面前當面告訴她, 即使我多了乙個朋友(沒辦法, 咱就喜歡交朋友), 也好過她收不到訊息的好. 這下可靠了, 我確信她收到了.
區別在**? 不是我到他面前, 而是不管她是否願意, 至少給爺們回句話吧. 沒錯, 就是回句話.
如果有這樣一種機制, 每次我發出去的資料, 如果對方收到了, 就給我回句話, 告訴我收到了, 那訊息就變得可靠了. 我發出去的所有訊息, 都可以確信對方已經收到了.
乙個來自靈魂的提問, 現在的資料傳送可靠嗎? 我覺得是不可靠的, 現在僅僅能夠保證乙個資料報, 我百分百的確信對方已經收到了. 那什麼樣的連線才是可靠的呢?
我要發你100個資料報, 那這100個資料報你每乙個都要能夠收到, 並且要按照順序將他們再拼裝起來, 我覺得這樣的連線才能稱得上可靠. 這裡面涉及到了兩個概念,確保收到和順序. 確保收到我們已經做到了, 如何保證包的順序呢? 我把要發的資料排排隊, 乙個乙個發就行了? 天真, 如果有包1在網路中某個地方喝了杯茶, 睡了一覺, 結果接收方先收到了包2後收到包1, 順序就亂了. 保證順序的方式其實很簡單, 在每乙個包上, 都加上乙個序號, 接收方按照序號從小到大把收到的包組裝起來就好了.
經過改造, 現在已經基本能夠保證傳輸的可靠性了, 到這裡, 有沒有發現什麼? 現在和tcp的區別就是少了三次握手和四次揮手(不僅僅是). 那三次握手的意義何在?
今天在接收了身邊大神的一些思想之後, 我還是沒有太明白. 不過現在, 我貌似明白了些什麼. 要想知道三次握手有什麼用, 就需要知道三次握手都做了什麼事情.
1. 確保對方能夠正常接收資料, 測試連線
還是上面的例子, 我去女神面前表白, 但不湊巧, 女神正在午休, 我站著旁邊傻傻的表白, 還是沒有用. 所以, 在開始之前, 我要先確保女神能夠聽到我說的話, 我得把她叫醒, 莊重的告訴她. 而這, 就是握手的意義.
2.建立系統開銷
在傳送 udp 包的時候, 因為其不可靠性, 所以基本不會用其傳送很大的檔案, 因為將較大的資料拆分後發出, 中間丟了幾個資料報就尷尬了. 而且 udp 也不能夠保證包的順序, 還是一樣的原因. 但是 tcp 就不一樣了, 它是可靠的啊, 你可以將多個資料報分開發給我, 到我這裡, 我再把他們按順序排列好就行了. 而這個按順序排列的操作就需要專門開闢記憶體空間來儲存收到的資料報了, 當握手成功後, 我就會為你留下用於儲存資料報的記憶體空間及其他一些系統資源.
而如果沒有三次握手呢? 客戶端傳送的資料報, 可能因為某些原因(比如路不好走), 在網路中待的久了一些, 客戶端因為沒有收到回覆, 已經放棄連線了, 但這時候, 伺服器收到了這個資料報, 開闢系統資源, 返回確認包, 然後就沒有然後了. 客戶端已經放棄了, 根本不搭理你的回覆. 系統的相關資源就白白浪費了.
3. 測試超時時間
上面說了, 當我長時間沒有收到你的回覆時, 我就認為你沒有收到我發出的資料, 那我就需要重新傳送了. 那這個長時間是多久呢? 可以在握手期間進行測試, 測量請求包的往返時間,並依此計算重傳的超時時間.
4.安全性
這個確實是我沒有想到的. 因為 tcp 會將資料拆分後傳送, 為了保證資料的有序, 就要給每個資料報進行編號. 然後接收方根據編號的順序對收到的包進行重組, 保證了資料的有序.
如果只是簡單的123456, 那大家都知道了, 我黑客小黑, 也給你發乙個編號為1的資料報, 不就把你真實的資料報給偷偷替換了麼? 為了防止序列號被猜到, 就要讓每次傳送資料的序列號不同, 在進行握手的時候會對資料的初始序列號進行交換. 客戶端第一次傳送握手資訊的時候, 會連著自己的初始序列號一起發過去, 伺服器收到之後, 返回第二個握手資訊的時候, 除了返回握手確認, 也會連著自己的初始序列號一起發回來. 這在一定程度上保證了資料的安全傳輸. 當然這種防護措施很弱.
這個隨機的序列號其實還有另外乙個作用, 我覺得這才是它最主要的作用. 如果我們上一次連線的其中乙個資料報3, 在網路中傲遊了一會, 連線已經斷開了, 我們又開始了新的一次資料連線, 這個時候我收到了資料報3, 就會導致生成了錯誤的資料序列, 而隨機序列號則避免了這個問題,
三次握手確實是有些作用, 那四次揮手有什麼用呢?
1.釋放系統資源
在三次握手的時候, 為了接收資料並進行序列重組, 開闢了一些系統資源, 當資料傳送完了, 就不用一直佔著了, 早些釋放, 留給別人.
額, 應該還有其他作用吧...
綜上, 你說如果沒有握手和揮手的過程, 能不能實現乙個可靠的連線呢? 可以, 只不過會有問題. 個人簡單將握手的作用總結為以下幾點:
為了對資料進行順序重組, 勢必需要開闢系統資源. 如果沒有握手的過程, 所有的請求, 都要占用資源. 而沒有揮手的過程, 這些資源就不能及時釋放.
為了資料的高效傳輸, 選用乙個合理的超時重傳時間是十分有必要的. 時間短了, 會導致頻繁重傳, 浪費網路資源. 時間長了, 就會導致整體的資料傳輸時間變長.
為了保證對方能夠正常接收資料, 否則對方關機了, 我總不能在這一直超時重傳吧.
為了保證多次連線的資料報不會引發資料錯誤. 通過隨機的序列號, 保證了兩次連線的資料報不會互相影響.
tcp三次握手 TCP 三次握手總結
tcp特點概述 tcp segment structure 段結構 step2 server host receives syn,replie with syn ack segment 答覆syn ack報文段 step3 client receives synack,replies with ac...
tcp的三次握手 傳輸層 TCP 三次握手
使用tcp協議進行通訊的雙方必須先建立連線，然後才能開始傳輸資料。為了確保連線雙方可靠性，在雙方建立連線時，tcp協議採用了三次握手策略。如圖 客戶端傳送帶有syn標誌的連線請求報文段，然後進入syn send狀態，等待服務端的確認。服務端接收到客戶端的syn報文段後，需要傳送ack資訊對這個syn...
TCP 三次握手
tcp 三次握手 tcp 連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號並交換 tcp 視窗大小資訊。以下步驟概述了通常情況下客戶端計算機聯絡伺服器計算機的過程 1.客戶端向伺服器傳送乙個syn置位的tcp報文，其中包含連線的初始序列號x和乙個視窗大小 表示客戶端上用來...