1.三次握手和四次揮手

1. 三次握手

• 第一次握手：Client將標(biāo)志位SYN置為1昼牛，隨機(jī)產(chǎn)生一個(gè)值seq=J雁歌，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。
• 第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接油啤，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1蟀苛，隨機(jī)產(chǎn)生一個(gè)值seq=K益咬，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求，Server進(jìn)入SYN_RCVD狀態(tài)屹逛。
• 第三次握手：Client收到確認(rèn)后础废，檢查ack是否為J+1，ACK是否為1罕模，如果正確則將標(biāo)志位ACK置為1评腺，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server淑掌，Server檢查ack是否為K+1蒿讥，ACK是否為1，如果正確則連接建立成功抛腕，Client和Server進(jìn)入ESTABLISHED狀態(tài)芋绸，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了担敌。

image

2. 四次揮手

• 第一次揮手：Client發(fā)送一個(gè)FIN摔敛，用來(lái)關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)全封。
• 第二次揮手：Server收到FIN后马昙，發(fā)送一個(gè)ACK給Client，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同刹悴，一個(gè)FIN占用一個(gè)序號(hào)）行楞，Server進(jìn)入CLOSE_WAIT狀態(tài)。此時(shí)TCP鏈接處于半關(guān)閉狀態(tài)土匀，即客戶端已經(jīng)沒(méi)有要發(fā)送的數(shù)據(jù)了子房，但服務(wù)端若發(fā)送數(shù)據(jù)，則客戶端仍要接收就轧。
• 第三次揮手：Server發(fā)送一個(gè)FIN证杭，用來(lái)關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)钓丰。

• 第四次揮手：Client收到FIN后躯砰，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server携丁，確認(rèn)序號(hào)為收到序號(hào)+1琢歇，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手梦鉴。

  
  
  image

2.為什么要三次握手

“三次握手” 的目的是為了防止已失效的鏈接請(qǐng)求報(bào)文突然又傳送到了服務(wù)端李茫，因而產(chǎn)生錯(cuò)誤。

• 正常的情況：A 發(fā)出連接請(qǐng)求肥橙，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)魄宏，于是 A 再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn)存筏，建立了連接宠互。數(shù)據(jù)傳輸完畢后味榛，就釋放了連接。A 共發(fā)送了兩個(gè)連接請(qǐng)求報(bào)文段予跌，其中第一個(gè)丟失搏色，第二個(gè)到達(dá)了 B。沒(méi)有 “已失效的連接請(qǐng)求報(bào)文段”券册。

• 現(xiàn)假定出現(xiàn)了一種異常情況：即 A 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失频轿，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá) B烁焙。本來(lái)這是一個(gè)早已失效的報(bào)文段航邢。但 B 收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是 A 再次發(fā)出的一個(gè)新的連接請(qǐng)求骄蝇。于是就向 A 發(fā)出確認(rèn)報(bào)文段膳殷，同意建立連接。(滯留后到達(dá)服務(wù)端的報(bào)文會(huì)引起服務(wù)端的響應(yīng)九火，此時(shí)客戶端已經(jīng)結(jié)束了連接不再發(fā)送資源秽之，服務(wù)端發(fā)出信息后，連接確認(rèn)吃既】颊ィ客戶端卻不發(fā)送任何數(shù)據(jù)，導(dǎo)致連接建立后浪費(fèi)服務(wù)端資源)
  假設(shè)不采用“三次握手”鹦倚，那么只要 B 發(fā)出確認(rèn)河质，新的連接就建立了。由于現(xiàn)在 A 并沒(méi)有發(fā)出建立連接的請(qǐng)求震叙，因此不會(huì)理睬 B 的確認(rèn)掀鹅，也不會(huì)向 B 發(fā)送數(shù)據(jù)。但 B 卻以為新的運(yùn)輸連接已經(jīng)建立媒楼，并一直等待 A 發(fā)來(lái)數(shù)據(jù)乐尊。這樣，B 的很多資源就白白浪費(fèi)掉了划址。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生扔嵌。

3.為什么要四次揮手？

TCP 協(xié)議是一種面向連接的夺颤、可靠的痢缎、基于字節(jié)流的運(yùn)輸層通信協(xié)議。TCP 是全雙工模式世澜，這就意味著独旷，當(dāng) A 向 B 發(fā)出 FIN 報(bào)文段時(shí)，只是表示 A 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，而此時(shí) A 還是能夠接受到來(lái)自 B 發(fā)出的數(shù)據(jù)嵌洼；B 向 A 發(fā)出 ACK 報(bào)文段也只是告訴 A 案疲，它自己知道 A 沒(méi)有數(shù)據(jù)要發(fā)了，但 B 還是能夠向 A 發(fā)送數(shù)據(jù)麻养。

4.HTTP

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬(wàn)維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議络拌。HTTP是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。

1. 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)回溺，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET混萝、HEAD遗遵、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同逸嘀。由于HTTP協(xié)議簡(jiǎn)單车要，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快崭倘。
2. 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象翼岁。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
3. 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求司光。服務(wù)器處理完客戶的請(qǐng)求琅坡，并收到客戶的應(yīng)答后，即斷開連接残家。采用這種方式可以節(jié)省傳輸時(shí)間榆俺。
4. 無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力坞淮。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息茴晋，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大回窘。另一方面诺擅，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。
5. 支持B/S及C/S模式啡直。
   請(qǐng)求步驟:

1烁涌、客戶端連接到Web服務(wù)器

一個(gè)HTTP客戶端，通常是瀏覽器酒觅，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接烹玉。例如，http://www.oakcms.cn阐滩。

2二打、發(fā)送HTTP請(qǐng)求

通過(guò)TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文掂榔，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行继效、請(qǐng)求頭部症杏、空行和請(qǐng)求數(shù)據(jù)4部分組成。

3瑞信、服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)

Web服務(wù)器解析請(qǐng)求厉颤，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本寫到TCP套接字凡简，由客戶端讀取逼友。一個(gè)響應(yīng)由狀態(tài)行、響應(yīng)頭部秤涩、空行和響應(yīng)數(shù)據(jù)4部分組成帜乞。

4、釋放連接TCP連接

若connection 模式為close筐眷，則服務(wù)器主動(dòng)關(guān)閉TCP連接黎烈，客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection 模式為keepalive匀谣，則該連接會(huì)保持一段時(shí)間照棋，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;

5、客戶端瀏覽器解析HTML內(nèi)容

客戶端瀏覽器首先解析狀態(tài)行武翎，查看表明請(qǐng)求是否成功的狀態(tài)代碼烈炭。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集宝恶∈崆欤客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語(yǔ)法對(duì)其進(jìn)行格式化卑惜，并在瀏覽器窗口中顯示膏执。
Content-Type:
請(qǐng)求的與實(shí)體對(duì)應(yīng)的MIME信息
Content-Type: application/x-www-form-urlencoded
例如： Content-Type: text/html;charset:utf-8;

• application/json ： JSON數(shù)據(jù)格式
• text/html ： HTML格式
• text/plain ：純文本格式

image.png

• 在HTTP/1.0中，默認(rèn)使用的是短連接露久。也就是說(shuō)更米，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接毫痕，但任務(wù)結(jié)束就中斷連接征峦。如果客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類型的 Web頁(yè)中包含有其他的Web資源，如JavaScript文件消请、圖像文件栏笆、CSS文件等；當(dāng)瀏覽器每遇到這樣一個(gè)Web資源臊泰，就會(huì)建立一個(gè)HTTP會(huì)話蛉加。
  但從 HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性针饥。使用長(zhǎng)連接的HTTP協(xié)議厂抽，會(huì)在響應(yīng)頭有加入這行代碼：
  Connection:keep-alive
• 在使用長(zhǎng)連接的情況下，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后丁眼，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會(huì)關(guān)閉筷凤，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接苞七。Keep-Alive不會(huì)永久保持連接藐守，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間蹂风。實(shí)現(xiàn)長(zhǎng)連接要客戶端和服務(wù)端都支持長(zhǎng)連接卢厂。

5.計(jì)算機(jī)網(wǎng)絡(luò)中五層 tcp屬于那一層 tcp具體實(shí)施

image.png

image.png

• TCP面向連接（如打電話要先撥號(hào)建立連接）;UDP是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接硫眨。
• TCP提供可靠的服務(wù)。也就是說(shuō)巢块，通過(guò)TCP連接傳送的數(shù)據(jù)礁阁，無(wú)差錯(cuò)，不丟失族奢，不重復(fù)姥闭，且按序到達(dá);UDP盡最大努力交付，即不保證可靠交付越走。
• Tcp通過(guò)校驗(yàn)和棚品，重傳控制，序號(hào)標(biāo)識(shí)廊敌，滑動(dòng)窗口铜跑、確認(rèn)應(yīng)答實(shí)現(xiàn)可靠傳輸。如丟包時(shí)的重發(fā)控制骡澈，還可以對(duì)次序亂掉的分包進(jìn)行順序控制锅纺。
• UDP具有較好的實(shí)時(shí)性，工作效率比TCP高肋殴，適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信囤锉。
• 每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對(duì)一，一對(duì)多护锤，多對(duì)一和多對(duì)多的交互通信官地。
• TCP對(duì)系統(tǒng)資源要求較多，UDP對(duì)系統(tǒng)資源要求較少烙懦。
• UDP 是一種面向無(wú)連接驱入，且不可靠的協(xié)議，在通信過(guò)程中，它并不像 TCP 那樣需要先建立一個(gè)連接沧侥，只要（目的地址可霎，端口號(hào)，源地址宴杀，端口號(hào)）確定了癣朗，就可以直接發(fā)送信息報(bào)文，并且不需要確保服務(wù)端一定能收到或收到完整的數(shù)據(jù)旺罢。它僅僅提供了校驗(yàn)和機(jī)制來(lái)保障一個(gè)報(bào)文是否完整旷余，若校驗(yàn)失敗，則直接丟棄報(bào)文扁达，不做任何處理正卧。

6.Http與Https

答：Http協(xié)議運(yùn)行在TCP之上，明文傳輸跪解，客戶端與服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份炉旷；Https是身披SSL(Secure Socket Layer)外殼的Http，運(yùn)行于SSL上叉讥，SSL運(yùn)行于TCP之上窘行，是添加了加密和認(rèn)證機(jī)制的HTTP。二者之間存在如下不同：

• 端口不同：Http與Http使用不同的連接方式图仓，用的端口也不一樣罐盔，前者是80，后者是443救崔；
• 資源消耗：和HTTP通信相比惶看，Https通信會(huì)由于加減密處理消耗更多的CPU和內(nèi)存資源；
• 開銷：Https通信需要證書六孵，而證書一般需要向認(rèn)證機(jī)構(gòu)購(gòu)買纬黎；Https的加密機(jī)制是一種共享密鑰加密和公開密鑰加密并用的混合加密機(jī)制。

7.TCP 的擁塞避免機(jī)制

擁塞：對(duì)資源的需求超過(guò)了可用的資源劫窒。網(wǎng)絡(luò)中許多資源同時(shí)供應(yīng)不足莹桅，整個(gè)網(wǎng)絡(luò)的吞吐量隨之負(fù)荷的增大而下降。對(duì)資源要求的總和>可用資源(通信流量>帶寬)
擁塞控制：防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中烛亦，使得網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載(數(shù)據(jù)包太多诈泼，路由器難以處理出現(xiàn)丟包)。
擁塞控制用于避免出現(xiàn)死鎖狀況煤禽，從而達(dá)到實(shí)際擁塞控制的狀況(路由器采用)

image.png

擁塞控制的方法：

1. 慢開始 + 擁塞避免：

• 慢開始：發(fā)送方維持擁塞窗口cwnd(congestion window)铐达，cwnd先從1開始慢慢加大，每經(jīng)過(guò)一個(gè)RTT且返回正常cwnd會(huì)成倍增長(zhǎng)檬果，發(fā)送速度越來(lái)越快瓮孙。當(dāng)達(dá)到了慢開始門限值唐断，正常的情況下下一輪cwnd+1(加法增大)。在出現(xiàn)丟包時(shí)(網(wǎng)絡(luò)擁塞)會(huì)計(jì)算一個(gè)新的慢開始門限(這個(gè)值等于出現(xiàn)丟包時(shí)的cwnd/2)杭抠。下一輪cwnd的值會(huì)從1指數(shù)增長(zhǎng)到新的慢開始門限脸甘，然后進(jìn)行線性增長(zhǎng)。
• 擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)偏灿，在cwnd超過(guò)慢開始門限后(ssthresh)每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1丹诀，而不是加倍，這樣擁塞窗口按線性規(guī)律緩慢增長(zhǎng)翁垂，直到出現(xiàn)擁塞現(xiàn)象后cwnd置1再次慢開始铆遭。
  
  image

2. 快重傳 + 快恢復(fù)：

• 快重傳：在以前的情況下B端會(huì)累計(jì)確認(rèn),即收到一組數(shù)據(jù)包后在進(jìn)行確認(rèn)。在得知一組數(shù)據(jù)包中的其中一個(gè)丟失沿猜，B端會(huì)連發(fā)三個(gè)確認(rèn)報(bào)文(含有需要重傳的序號(hào))讓A端重新發(fā)送這個(gè)丟失的報(bào)文而不是等到接收完一組后再發(fā)確認(rèn)信息要求重傳枚荣。發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期啼肩。在出現(xiàn)丟包的情況下網(wǎng)絡(luò)可能快擁塞了橄妆，此時(shí)接收端即時(shí)發(fā)送三個(gè)含序號(hào)的確認(rèn)包(連著收到三個(gè)確認(rèn)說(shuō)明此刻未擁塞但可能會(huì)進(jìn)入擁塞狀態(tài))。
• 快恢復(fù)：快重傳配合使用的還有快恢復(fù)算法祈坠，當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)害碾，就立刻把ssthresh門限減半，但是接下去并不執(zhí)行慢開始算法：因?yàn)槿绻W(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)颁虐，所以發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)可能沒(méi)有出現(xiàn)擁塞蛮原。所以此時(shí)不執(zhí)行慢開始算法卧须，而是將cwnd設(shè)置為ssthresh的大小另绩，然后執(zhí)行擁塞避免算法。就會(huì)把cwnd設(shè)置為慢開始門限的大小花嘶，從新的慢開始門限值進(jìn)行線性增加笋籽。

發(fā)送窗口上限值 =Min[rwnd,cwnd],由接收窗口控制與發(fā)送出窗口的擁塞窗口指定。

image

8.瀏覽器中輸入：“www.xxx.com” 之后都發(fā)生了什么椭员？請(qǐng)?jiān)敿?xì)闡述车海。

1. 由域名→IP地址 尋找IP地址的過(guò)程依次經(jīng)過(guò)了瀏覽器緩存、系統(tǒng)緩存隘击、hosts文件侍芝、路由器緩存、 遞歸搜索根域名服務(wù)器埋同。
2. 建立TCP/IP連接（三次握手具體過(guò)程）
3. 由瀏覽器發(fā)送一個(gè)HTTP請(qǐng)求
4. 經(jīng)過(guò)路由器的轉(zhuǎn)發(fā)州叠，通過(guò)服務(wù)器的防火墻，該HTTP請(qǐng)求到達(dá)了服務(wù)器
5. 服務(wù)器處理該HTTP請(qǐng)求凶赁，返回一個(gè)HTML文件
6. 瀏覽器解析該HTML文件咧栗，并且顯示在瀏覽器端

9.TCP 協(xié)議如何來(lái)保證傳輸?shù)目煽啃?/h3>

TCP 提供一種面向連接的逆甜、可靠的字節(jié)流服務(wù)。其中致板，面向連接意味著兩個(gè)使用 TCP 的應(yīng)用（通常是一個(gè)客戶和一個(gè)服務(wù)器）在彼此交換數(shù)據(jù)之前必須先建立一個(gè) TCP 連接交煞。在一個(gè) TCP 連接中，僅有兩方進(jìn)行彼此通信斟或；而字節(jié)流服務(wù)意味著兩個(gè)應(yīng)用程序通過(guò) TCP 鏈接交換 8 bit 字節(jié)構(gòu)成的字節(jié)流素征，TCP 不在字節(jié)流中插入記錄標(biāo)識(shí)符。

• 停止等待協(xié)議：(正常情況)發(fā)送數(shù)據(jù)包后必須等待確認(rèn)才會(huì)選擇繼續(xù)讓其發(fā)送缕粹，否則等待稚茅。(超時(shí)重傳)發(fā)出一個(gè)數(shù)據(jù)包后等待一個(gè)RTT時(shí)間(往返)后若沒(méi)有收到確認(rèn)信息，將重新發(fā)送這個(gè)報(bào)文(默認(rèn)丟失,不確認(rèn)就重傳)平斩。(確認(rèn)包丟失)A端發(fā)M1B端收到后,B端發(fā)給A端的確認(rèn)包丟失,A端會(huì)認(rèn)為超時(shí)重傳會(huì)再發(fā)一次M1亚享，此時(shí)B端不接受M1但會(huì)再發(fā)送確認(rèn)包信息給A端。(確認(rèn)包遲到)B端發(fā)給A端的確認(rèn)包遲到绘面，A端默認(rèn)丟失超時(shí)重傳欺税，B端接收后再次發(fā)送確認(rèn)包，A端收到遲到的確認(rèn)包時(shí)什么也不做揭璃。(只有收到確認(rèn)信息才繼續(xù)晚凿，否則重發(fā),在不可靠的網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的TCP通信ARQ)。
• 連續(xù)ARQ(發(fā)送窗口)：發(fā)送方維持發(fā)送窗口瘦馍，可以一次性發(fā)送窗口大小這么多個(gè)數(shù)據(jù)包然后等待確認(rèn)報(bào)文歼秽，得到確認(rèn)后窗口滑動(dòng)發(fā)送新的字節(jié)流報(bào)文∏樽椋互相根據(jù)對(duì)方的接收緩存設(shè)置(65535)發(fā)送窗口大小(1460)
• 滑動(dòng)窗口：發(fā)送方和接收方都有緩沖區(qū)燥筷，發(fā)送時(shí)會(huì)維護(hù)一個(gè)以字節(jié)為單位的滑動(dòng)窗口，如果收到確認(rèn)后窗口就會(huì)滑動(dòng)院崇，發(fā)送緩沖區(qū)會(huì)丟棄已發(fā)送的字節(jié)肆氓，B端發(fā)送確認(rèn)報(bào)文后，窗口移動(dòng)(確認(rèn)報(bào)文含有下一步該發(fā)哪一個(gè)字節(jié)組成的報(bào)文)底瓣。接收窗口先移動(dòng)谢揪，然后發(fā)送端口移動(dòng)。窗口到底后循環(huán)使用
• 數(shù)據(jù)包校驗(yàn)：目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化捐凭，若校驗(yàn)出包有錯(cuò)拨扶，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí)TCP發(fā)送數(shù)據(jù)端超時(shí)后會(huì)重發(fā)數(shù)據(jù)茁肠。TCP首部中的確認(rèn)序號(hào)表示已成功收到字節(jié)患民，但還不包括確認(rèn)序號(hào)所指的字節(jié)。希望下一次能收到確認(rèn)序號(hào)所指的字節(jié)官套。 發(fā)送端初始時(shí)序號(hào)為1酒奶，同時(shí)會(huì)發(fā)送下一次將會(huì)發(fā)送的起始序號(hào)蚁孔，接收端接收后返回確認(rèn)同時(shí)包含發(fā)送端下一次發(fā)送的起始序號(hào)。若返回的是確認(rèn)信息(已發(fā)送的包都沒(méi)必要重傳)則發(fā)送端窗口移動(dòng)惋嚎。
• 對(duì)丟失的數(shù)據(jù)包段發(fā)送選擇型確認(rèn)：若A端發(fā)送的數(shù)據(jù)包有丟失的情況,B端會(huì)返回確認(rèn)包(SAK選擇型確認(rèn))會(huì)告訴A端哪個(gè)序號(hào)部分的丟失杠氢，A端會(huì)重新發(fā)這一個(gè)數(shù)據(jù)包，然后發(fā)送窗口往前移動(dòng)
• 丟棄重復(fù)數(shù)據(jù)：對(duì)于重復(fù)數(shù)據(jù)另伍，能夠丟棄重復(fù)數(shù)據(jù)鼻百；
• 應(yīng)答機(jī)制：當(dāng)TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)摆尝。這個(gè)確認(rèn)不是立即發(fā)送温艇，通常將推遲幾分之一秒；
• 超時(shí)重發(fā)：當(dāng)TCP發(fā)出一個(gè)段后堕汞，它啟動(dòng)一個(gè)計(jì)時(shí)器勺爱，等待接收端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段，時(shí)間稍大于RTT
• 流量控制：TCP連接的每一方都有固定大小的緩沖空間志膀。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出围段，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議投放。對(duì)于發(fā)送端A端與接收端B端奈泪，A有發(fā)送緩存而B有接收緩存，要發(fā)送的數(shù)據(jù)先放到A的發(fā)送緩存灸芳，建立會(huì)話時(shí)B端設(shè)置自己的接收窗口(發(fā)送Ack涝桅，rwnd(receive window)=10(字節(jié)))。A根據(jù)此設(shè)置發(fā)送窗口耗绿，此時(shí)可以連續(xù)發(fā)送數(shù)據(jù)包苹支。B端會(huì)根據(jù)自己的情況回復(fù)成功報(bào)文(包括rwnd)砾隅，若B端壓力過(guò)大rwnd的值會(huì)縮小误阻，待B端處理后rwnd的值再進(jìn)行擴(kuò)展，若含有rwnd的包遺失晴埂，A端會(huì)定時(shí)發(fā)包詢問(wèn)究反。通過(guò)接收端告訴發(fā)送端接收窗口的大小來(lái)防止緩沖區(qū)溢出。

10.TCP與UDP分別對(duì)應(yīng)的常用協(xié)議儒洛。

TCP對(duì)應(yīng)協(xié)議

• FTP：21端口用于連接精耐，20端口用于傳輸數(shù)據(jù)。定義了文件傳輸協(xié)議琅锻，使用21端口卦停。常說(shuō)某某計(jì)算機(jī)開了FTP服務(wù)便是啟動(dòng)了文件傳輸服務(wù)向胡。下載文件，上傳主頁(yè)惊完，都要用到FTP服務(wù)僵芹。我們平常下載文件時(shí)，會(huì)遇到下載到99%時(shí)小槐，文件不完成拇派，不能成功的下載。
  其實(shí)是因?yàn)槲募螺d完畢后凿跳，還要在21端口再行進(jìn)行用戶認(rèn)證件豌，而下載文件的時(shí)間如果過(guò)長(zhǎng)，客戶機(jī)與服務(wù)器的21端口的連接會(huì)被服務(wù)器認(rèn)為是超時(shí)連接而中斷掉控嗜，就是這個(gè)原因茧彤。解決方法就是設(shè)置21端口的響應(yīng)時(shí)間。
• SMTP：定義了簡(jiǎn)單郵件傳送協(xié)議疆栏，現(xiàn)在很多郵件服務(wù)器都用的是這個(gè)協(xié)議棘街，用于發(fā)送郵件。如常見的免費(fèi)郵件服務(wù)中用的就是這個(gè)郵件服務(wù)端口承边，所以在電子郵件設(shè)置-中吃庋常看到有這么SMTP端口設(shè)置這個(gè)欄，服務(wù)器開放的是25號(hào)端口博助。
• POP3：它是和SMTP對(duì)應(yīng)险污，POP3用于接收郵件。通常情況下富岳，POP3協(xié)議所用的是110端口蛔糯。也是說(shuō)，只要你有相應(yīng)的使用POP3協(xié)議的程序（例如Fo-xmail或Outlook）窖式，就可以不以Web方式登陸進(jìn)郵箱界面蚁飒，直接用郵件程序就可以收到郵件（如是163郵箱就沒(méi)有必要先進(jìn)入網(wǎng)易網(wǎng)站，再進(jìn)入自己的郵-箱來(lái)收信）萝喘。

UDP對(duì)應(yīng)協(xié)議

• DNS：用于域名解析服務(wù)淮逻，將域名地址轉(zhuǎn)換為IP地址。DNS用的是53號(hào)端口阁簸。
• SNMP：簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議爬早，使用161號(hào)端口，是用來(lái)管理網(wǎng)絡(luò)設(shè)備的启妹。由于網(wǎng)絡(luò)設(shè)備很多筛严，無(wú)連接的服務(wù)就體現(xiàn)出其優(yōu)勢(shì)。
• TFTP(Trival File Transfer Protocal)：簡(jiǎn)單文件傳輸協(xié)議饶米，該協(xié)議在熟知端口69上使用UDP服務(wù)

作者：我沒(méi)有三顆心臟
鏈接：http://www.reibang.com/p/210f85108c52
來(lái)源：簡(jiǎn)書
簡(jiǎn)書著作權(quán)歸作者所有桨啃，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處车胡。