詳解TCP協(xié)議三次握手全過程
本文只是為了便于理解,做非常寬泛的描述,措辭不甚嚴(yán)謹(jǐn),不當(dāng)之處還望指正,感謝。 看本文章之前,建議對OSI模型已經(jīng)TCP/IP不太了解的同學(xué)們,看看我之前寫的 白話解釋 OSI模型,TLS/SSL 及 HTTPS
本文引用地址:http://www.ex-cimer.com/article/201801/374917.htm一切為了傳輸 UDP vs TCP
互聯(lián)網(wǎng)之所以偉大的原因之一是解決了遠距離可靠傳輸信息的問題,既然要進行“互相”傳輸數(shù)據(jù)那么肯定是有一定的規(guī)則和協(xié)議的,TCP和UDP就是兩種廣泛應(yīng)用的傳輸協(xié)議,在這里做一個簡單的比較:
UDP (你把它想象成平郵信件),往往郵遞員會集中把信件放在郵局,比如一個學(xué)校的郵政,但是這種方式不可靠啊,因為這種平郵的信件老是容易“丟包”,也就是說,這種傳輸方式?jīng)]法確保收件人一定能收到信件。
這不行啊,所以,人們就想到了一種更為可靠的傳輸方式:
TCP(你把它想象成快遞),快遞員可以直接送貨上門,即使不送貨上門,可要給你打電話,檢查你的身份證,讓你簽字等等,確保你的包裹不會被丟失。所以,這種方式更“可靠”。
TCP vs UDP 誰更可靠
上面的例子也已經(jīng)很清楚的看到,TCP(快遞)之所以可靠,是因為有種種的“檢查”機制,當(dāng)快遞的“包裹”真正到達收件人手里的時候,這個”傳輸“過程才算完成,否則快遞小哥就“重新投遞“。那么”UDP“(平郵信件)就不管這一套,反正根據(jù)信件上的地址把”傳輸?shù)男偶叭釉谧罱泥]件或者上面所寫的信箱中就完事,至于隨后包裹到底到?jīng)]到收件人手中,這個UDP不管了。
所以,到現(xiàn)在,我們知道了,TCP傳輸數(shù)據(jù)比udp更加“可靠”!
TCP存在之于”互聯(lián)網(wǎng)“的意義
我們現(xiàn)在能在互聯(lián)網(wǎng)上看文章,直播,視頻,娛樂,購物,甚至網(wǎng)上轉(zhuǎn)賬,當(dāng)然,看直播的話,UDP協(xié)議還是不錯滴,但是,如果涉及到金錢或者敏感數(shù)據(jù),如果都像沒有一套“可靠”的傳輸協(xié)議,誰還敢在網(wǎng)上“轉(zhuǎn)賬”,“存儲信息”呢?
我們已經(jīng)知道了,TCP存在的意義之一就是: ”可靠的傳輸“ ,但同時要進行遠程通信, ”高效的傳輸“ 是必不可少的,最后,數(shù)據(jù)包在混沌險惡的互聯(lián)網(wǎng)中穿梭, ”安全的傳輸“ 是必須的。
所以,小結(jié)一下,TCP存在之于”互聯(lián)網(wǎng)“的意義有三點(重要的事情說三遍): - 讓數(shù)據(jù)進行”可靠“,”高效“,”安全“的傳輸 - 讓數(shù)據(jù)進行”可靠“,”高效“,”安全“的傳輸 - 讓數(shù)據(jù)進行”可靠“,”高效“,”安全“的傳輸
請注意:這里所說的”高效”只是相對TCP自己而言,因為這個”高效“會和后面我們會說到三次握手其中的第二步合并的握手相關(guān),所以我在這里提一下,其實,UDP會因為沒有了一些檢測機制會比TCP更加高效,快速。
一定的代價
都說”魚和熊掌不能兼得“,對于TCP來說更是如此,既然選擇了”可靠“,”高效“和”安全“作為己任,那么就必然要想一些辦法讓自己滿足這些特征,那么TCP怎么辦的呢?
可靠
數(shù)據(jù)的可靠性意味著接收方接收到了準(zhǔn)確無誤的信息,如果中間有丟包,要有一定的機制讓發(fā)送方重新發(fā)送。TCP怎么辦的呢?它是這么辦的:
發(fā)送方通過一定方式告訴接收方,所傳輸?shù)臄?shù)據(jù)包有多大,然后分幾次,比如:數(shù)據(jù)包總共100kb,然后分10次發(fā)送,這時候接收方就知道總共有10個數(shù)據(jù)包,同時發(fā)送方會在每個數(shù)據(jù)包上標(biāo)記上號碼,然后TCP從數(shù)據(jù)包1開始接受,逐次加一,知道接收到第十個結(jié)束,只有這10個全部確認(rèn)收到了,接收方才確認(rèn)這個通信完成,所以確保了數(shù)據(jù)的可靠性。
那么問題來了,接收方怎么知道數(shù)據(jù)包共100kb,然后又怎么知道什么時候開始算是接受這個包?什么時候接受完成呢?這個時候就是第一次握手的開始,也可以說是第一次交流的開始。
比如:張三(發(fā)送方)要發(fā)信息給李四(接收方)。
1. 張三:hi,李四,我想發(fā)送一個100kb的數(shù)據(jù)包,打算分10次發(fā)送,你那邊能接一下么?
2. 李四:好的,收到,你發(fā)吧。
3. 張三:ok, 太棒了!
4. 張三:數(shù)據(jù)包1..2..3..4...5..6..7..8..9..10
那么,可不可以不打招呼直接發(fā)?也就是一次握手。當(dāng)然可以,就像UDP平郵似的,發(fā)唄,只不過有可能接收方收不到信息而已,發(fā)送方也不知道接收方收到還是沒收到,就是得不到保障而已。
安全
大家有沒有覺得有什么問題呢? 安全問題! 如果上面第四步張三在給李四發(fā)的時候,數(shù)據(jù)包編號每次總是從1開始,那么豈不是太容易被猜測?如果這樣的話,”黑客小黑“可以在與此同時發(fā)送帶有同樣編號的數(shù)據(jù)包,反正編號都從1開始,猜唄,因為TCP很傻,所以只要是編號相同就接受了,那樣就不太安全,黑客就可以猜到這些數(shù)據(jù)包的編號了。
這里說的數(shù)據(jù)包編號,其實是在TCP頭信息中的”序列號“(sequence number),上面這種攻擊方式叫做: TCP序列號預(yù)測攻擊(TCP_sequence_prediction_attack)
所以,為了防止序列號被踩到,我們引入一種隨機序列號的方式進行提高,就是在張三和李四第一次握手的時候,張三同時在數(shù)據(jù)包中加入一個隨機序列號,發(fā)送給李四,然后因為李四收到張三的請求信息后還需要發(fā)送確認(rèn)信息回給張三,這時候,李四就成了發(fā)送方了,所以李四也需要隨機出一個序列號給張三,為的也是張三那邊能夠安全可靠的得到李四的信息,這里我們看到,在第二次握手的時候,李四需要:
確認(rèn)張三的請求
發(fā)送自己的隨機序列號
本來是兩個步驟的,但是,TCP為了 ”相對高效“ 的傳輸,就把這兩步”整合“到了一步中了,然后最后一步就是,張三收到來自李四的“確認(rèn)”以及“隨機序列號”,然后再給李四發(fā)回一個“確認(rèn)”消息,至此,三次握手結(jié)束,信息傳輸就開始了。
所以我們把上面的栗子改進提高一下,就變成了:
1. 張三:hi,李四,我想發(fā)送一個100kb的數(shù)據(jù)包,打算分10次發(fā)送,為了防止別人猜我發(fā)的數(shù)據(jù)包編號,這是我隨機出來的一個初始序列號,9381921,你那邊能接一下么? (SYN)
2. 李四:好的,收到(ACK),這是我隨機出來的初始序列號,2342322,你發(fā)吧。(SYN)
3. 張三:ok, 太棒了!(ACK)
4. 張三:數(shù)據(jù)包9381921
5. 李四:收到數(shù)據(jù)包9381921,序列號:2342322
6. 張三:數(shù)據(jù)包9381922
7. 李四:收到數(shù)據(jù)包9381922,序列號:2342323
...
大家請注意上面我在對話中標(biāo)注的:SYN及ACK,就是TCP三次握手的過程:
發(fā)送方給接收方發(fā)送SYN信號
接收方確認(rèn)并回復(fù)給發(fā)送方SYN/ACK信號
發(fā)送方給接收方發(fā)送確認(rèn)ACK信號
為什么TCP需要三次握手
我相信大家已經(jīng)對上面三次握手流程有了一個比較清晰的認(rèn)識了,那么,我們現(xiàn)在回到文章的主題,為什么TCP需要三次握手呢?為什么不是一次,兩次或四次呢?我不妨用一個問句來回答這個問題吧: 如果是一次,兩次或四次,怎么才能保證TCP的“可靠”,“安全”及“高效”的傳輸呢?
評論