姓名：王重月? 學(xué)號(hào)：21021211019? ?學(xué)院：電子工程學(xué)院
轉(zhuǎn)自：(30條消息) 嵌入式必備知識(shí)_Oliver.H的博客-CSDN博客_嵌入式基本知識(shí)必備
【嵌牛導(dǎo)讀】TCP和UDP
【嵌牛鼻子】TCP和UDP的相關(guān)概念，延伸
【嵌牛提問(wèn)】TCP和UDP的區(qū)別等
【嵌牛正文】
3.1 TCP UDP
3.1.1 TCP、UDP的區(qū)別
1） 連接
TCP是面向連接的傳輸層協(xié)議，即傳輸數(shù)據(jù)之前必須先建立好連接。
UDP無(wú)連接。
2） 服務(wù)對(duì)象
TCP是點(diǎn)對(duì)點(diǎn)的兩點(diǎn)間服務(wù)，即一條TCP連接只能有兩個(gè)端點(diǎn)；
UDP支持一對(duì)一，一對(duì)多，多對(duì)一，多對(duì)多的交互通信。
3） 可靠性
TCP是可靠交付：無(wú)差錯(cuò)，不丟失，不重復(fù)，按序到達(dá)。
UDP是盡最大努力交付，不保證可靠交付。
4）擁塞控制，流量控制
TCP有擁塞控制和流量控制保證數(shù)據(jù)傳輸?shù)陌踩浴?/p>
UDP沒(méi)有擁塞控制，網(wǎng)絡(luò)擁塞不會(huì)影響源主機(jī)的發(fā)送效率。
5） 報(bào)文長(zhǎng)度
TCP是動(dòng)態(tài)報(bào)文長(zhǎng)度，即TCP報(bào)文長(zhǎng)度是根據(jù)接收方的窗口大小和當(dāng)前網(wǎng)絡(luò)擁塞情況決定的。
UDP面向報(bào)文，不合并，不拆分，保留上面?zhèn)飨聛?lái)報(bào)文的邊界。
6）首部開(kāi)銷
TCP首部開(kāi)銷大，首部20個(gè)字節(jié)。
UDP首部開(kāi)銷小，8字節(jié)。（源端口，目的端口，數(shù)據(jù)長(zhǎng)度，校驗(yàn)和）
3.1.2 TCP、UDP的優(yōu)缺點(diǎn)
從特點(diǎn)上我們已經(jīng)知道，TCP 是可靠的但傳輸速度慢，UDP 是不可靠的但傳輸速度快。因此在選用具體協(xié)議通信時(shí)，應(yīng)該根據(jù)通信數(shù)據(jù)的要求而決定。
3.1.3 TCP UDP適用場(chǎng)景
若通信數(shù)據(jù)完整性需讓位與通信實(shí)時(shí)性，則應(yīng)該選用TCP 協(xié)議（如文件傳輸、重要狀態(tài)的更新等）；反之，則使用 UDP 協(xié)議（如視頻傳輸、實(shí)時(shí)通信等）。
3.1.4 TCP為什么是可靠連接
（1）序列號(hào)、確認(rèn)應(yīng)答、超時(shí)重傳
數(shù)據(jù)到達(dá)接收方，接收方需要發(fā)出一個(gè)確認(rèn)應(yīng)答，表示已經(jīng)收到該數(shù)據(jù)段，并且確認(rèn)序號(hào)會(huì)說(shuō)明了它下一次需要接收的數(shù)據(jù)序列號(hào)。如果發(fā)送發(fā)遲遲未收到確認(rèn)應(yīng)答，那么可能是發(fā)送的數(shù)據(jù)丟失，也可能是確認(rèn)應(yīng)答丟失，這時(shí)發(fā)送方在等待一定時(shí)間后會(huì)進(jìn)行重傳。這個(gè)時(shí)間一般是2*RTT(報(bào)文段往返時(shí)間）+一個(gè)偏差值。
（2）窗口控制與高速重發(fā)控制/快速重傳（重復(fù)確認(rèn)應(yīng)答）
TCP會(huì)利用窗口控制來(lái)提高傳輸速度，意思是在一個(gè)窗口大小內(nèi)，不用一定要等到應(yīng)答才能發(fā)送下一段數(shù)據(jù)，窗口大小就是無(wú)需等待確認(rèn)而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。如果不使用窗口控制，每一個(gè)沒(méi)收到確認(rèn)應(yīng)答的數(shù)據(jù)都要重發(fā)。
使用窗口控制，如果數(shù)據(jù)段1001-2000丟失，后面數(shù)據(jù)每次傳輸，確認(rèn)應(yīng)答都會(huì)不停地發(fā)送序號(hào)為1001的應(yīng)答，表示我要接收1001開(kāi)始的數(shù)據(jù)，發(fā)送端如果收到3次相同應(yīng)答，就會(huì)立刻進(jìn)行重發(fā)；但還有種情況有可能是數(shù)據(jù)都收到了，但是有的應(yīng)答丟失了，這種情況不會(huì)進(jìn)行重發(fā)，因?yàn)榘l(fā)送端知道，如果是數(shù)據(jù)段丟失，接收端不會(huì)放過(guò)它的，會(huì)瘋狂向它提醒…
（3）擁塞控制
擁塞控制是防止過(guò)多的數(shù)據(jù)注入網(wǎng)絡(luò)，使得網(wǎng)絡(luò)中的路由器或者鏈路過(guò)載。流量控制是點(diǎn)對(duì)點(diǎn)的通信量控制，而擁塞控制是全局的網(wǎng)絡(luò)流量整體性的控制。發(fā)送雙方都有一個(gè)擁塞窗口——cwnd。
慢啟動(dòng)：
最開(kāi)始發(fā)送方的擁塞窗口為1，由小到大逐漸增大發(fā)送窗口和擁塞窗口。每經(jīng)過(guò)一個(gè)傳輸輪次，擁塞窗口cwnd加倍。當(dāng)cwnd超過(guò)慢開(kāi)始門(mén)限，則使用擁塞避免算法，避免cwnd增長(zhǎng)過(guò)大。
擁塞避免：
每經(jīng)過(guò)一個(gè)往返時(shí)間RTT，cwnd就增長(zhǎng)1。
在慢開(kāi)始和擁塞避免的過(guò)程中，一旦發(fā)現(xiàn)網(wǎng)絡(luò)擁塞，就把慢開(kāi)始門(mén)限設(shè)為當(dāng)前值的一半，并且重新設(shè)置cwnd為1，重新慢啟動(dòng)。（乘法減小，加法增大）
快速重傳
接收方每次收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)，發(fā)送方只要連續(xù)收到三個(gè)重復(fù)確認(rèn)就立即重傳（盡早重傳未被確認(rèn)的報(bào)文段）。
快恢復(fù)
當(dāng)發(fā)送方連續(xù)收到了三個(gè)重復(fù)確認(rèn)，就乘法減半（慢開(kāi)始門(mén)限減半），將當(dāng)前的cwnd設(shè)置為慢開(kāi)始門(mén)限，并且采用擁塞避免算法（連續(xù)收到了三個(gè)重復(fù)請(qǐng)求，說(shuō)明當(dāng)前網(wǎng)絡(luò)可能沒(méi)有擁塞）。
采用快恢復(fù)算法時(shí)，慢開(kāi)始只在建立連接和網(wǎng)絡(luò)超時(shí)才使用。
3.1.5典型網(wǎng)絡(luò)模型，簡(jiǎn)單說(shuō)說(shuō)有哪些
OSI七層模型及其包含的協(xié)議如下:
物理層: 通過(guò)媒介傳輸比特,確定機(jī)械及電氣規(guī)范,傳輸單位為bit，主要包括的協(xié)議為：IEE802.3 CLOCK RJ45
數(shù)據(jù)鏈路層: 將比特組裝成幀和點(diǎn)到點(diǎn)的傳遞,傳輸單位為幀,主要包括的協(xié)議為MAC VLAN PPP
網(wǎng)絡(luò)層：負(fù)責(zé)數(shù)據(jù)包從源到宿的傳遞和網(wǎng)際互連，傳輸單位為包,主要包括的協(xié)議為IP ARP ICMP
傳輸層：提供端到端的可靠報(bào)文傳遞和錯(cuò)誤恢復(fù)，傳輸單位為報(bào)文,主要包括的協(xié)議為T(mén)CP UDP
會(huì)話層：建立、管理和終止會(huì)話，傳輸單位為SPDU，主要包括的協(xié)議為RPC NFS
表示層: 對(duì)數(shù)據(jù)進(jìn)行翻譯、加密和壓縮,傳輸單位為PPDU，主要包括的協(xié)議為JPEG ASII
應(yīng)用層: 允許訪問(wèn)OSI環(huán)境的手段,傳輸單位為APDU，主要包括的協(xié)議為FTP HTTP DNS
TCP/IP 4層模型包括：
網(wǎng)絡(luò)接口層：MAC VLAN
網(wǎng)絡(luò)層:IP ARP ICMP
傳輸層:TCP UDP
應(yīng)用層:HTTP DNS SMTP
經(jīng)典五層模型：
應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層
3.1.6 Http1.1和Http1.0的區(qū)別
1，HTTP/1.0協(xié)議使用非持久連接,即在非持久連接下,一個(gè)tcp連接只傳輸一個(gè)Web對(duì)象,；
2，HTTP/1.1默認(rèn)使用持久連接(然而,HTTP/1.1協(xié)議的客戶機(jī)和服務(wù)器可以配置成使用非持久連接)。
在持久連接下,不必為每個(gè)Web對(duì)象的傳送建立一個(gè)新的連接,一個(gè)連接中可以傳輸多個(gè)對(duì)象
HTTP/1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器每次都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求后，立即斷開(kāi)TCP連接，也就是說(shuō)，同一個(gè)客戶第二次訪問(wèn)同一個(gè)服務(wù)器上的頁(yè)面時(shí)，服務(wù)器的響應(yīng)過(guò)程與第一次被訪問(wèn)時(shí)是相同的。舉例在收到的HTML文檔后，文檔中有10個(gè)圖片，每個(gè)圖片都要重新再次建立連接獲取，所以網(wǎng)速較慢的時(shí)候，我們有時(shí)會(huì)看到先出現(xiàn)網(wǎng)頁(yè)，每個(gè)圖片再逐一出現(xiàn)。
這樣做的好處：簡(jiǎn)化了服務(wù)器的設(shè)計(jì)，是服務(wù)器更容易支持大量并發(fā)的HTTP請(qǐng)求
這樣做的缺點(diǎn)：每請(qǐng)求一個(gè)文檔就要有兩倍RTT的開(kāi)銷 ，詳細(xì)過(guò)程：HTTP協(xié)議首先要和服務(wù)器建立TCP連接，這需要三次握手，當(dāng)三次握手的前兩部分經(jīng)過(guò)一個(gè)RTT完成后，客戶就把HTTP請(qǐng)求報(bào)文作為第三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給萬(wàn)維網(wǎng)服務(wù)器，服務(wù)器收到HTTP請(qǐng)求報(bào)文后，就把所請(qǐng)求的文檔作為響應(yīng)報(bào)文返回給客戶。每個(gè)請(qǐng)求文檔花費(fèi)兩倍的RTT時(shí)間。
HTTP/1.1支持持續(xù)連接和流水線方式
持續(xù)連接就是萬(wàn)維網(wǎng)服務(wù)器在發(fā)送響應(yīng)后仍然在一段時(shí)間內(nèi)保持這條連接，使同一個(gè)客戶（瀏覽器）和該服務(wù)器可以繼續(xù)在這條連接上傳送后續(xù)的HTTP請(qǐng)求報(bào)文和響應(yīng)報(bào)文。這條持續(xù)的連接并不局限于傳輸同一個(gè)頁(yè)面上鏈接的文檔，而是只要文檔在同一個(gè)服務(wù)器上就可以通過(guò)這條持續(xù)的連接傳送。
流水線方式是客戶在收到HTTP的響應(yīng)報(bào)文之前就能接著發(fā)送新的請(qǐng)求報(bào)文。與之相對(duì)應(yīng)的非流水線方式是客戶在收到前一個(gè)響應(yīng)后才能發(fā)送下一個(gè)請(qǐng)求。
3.1.7 URI（統(tǒng)一資源標(biāo)識(shí)符）和URL（統(tǒng)一資源定位符）之間的區(qū)別
URL
URL 統(tǒng)一資源定位符（Uniform Resource Locator），其實(shí)就是我們?cè)L問(wèn)web頁(yè)面時(shí)需要輸入的”網(wǎng)頁(yè)地址“”網(wǎng)址“，比如：https://www.google.com/ 就是URL。
完整定義如下：
協(xié)議類型 : // 登錄信息（認(rèn)證） @ 服務(wù)器地址 : 端口號(hào) / 帶層次的文件路徑 ? 查詢字符串 # 片段標(biāo)識(shí)符
htttp : // user:pass @ www.example.jp : 80 / dir/index.html ? uid=1 # ch
URI
URI 統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifier），就是某個(gè)網(wǎng)絡(luò)協(xié)議方案表示的資源的定位標(biāo)識(shí)符，比如：https://www.google.com/ 也同樣可以說(shuō)是，在https網(wǎng)絡(luò)協(xié)議下的一個(gè)URI。
如果想要了解 URI統(tǒng)一資源標(biāo)識(shí)符，那么我們必須理清它和 URL統(tǒng)一資源定位符 之間的關(guān)系。
第一，URL統(tǒng)一資源定位符 是一個(gè)具體的概念，而 URI統(tǒng)一資源標(biāo)識(shí)符 是一個(gè)抽象的概念。
第二，URL統(tǒng)一資源定位符 是 URI統(tǒng)一資源標(biāo)識(shí)符 的子集，URL 屬于 URI。
3.2 三次握手、四次揮手
3.2.1什么是三次握手
Client將標(biāo)志位SYN（同步號(hào)）置為1，隨機(jī)產(chǎn)生一個(gè)（序列號(hào)）seq=x，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT(同步發(fā)送)狀態(tài)，等待Server確認(rèn)。
Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接，Server將（同步號(hào)）SYN和ACK都置為1，產(chǎn)生一個(gè)（確認(rèn)號(hào)）ack=x+1，隨機(jī)產(chǎn)生一個(gè)值（序列號(hào)）seq=y，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求，Server進(jìn)入SYN_RCVD(同步接受)狀態(tài)。
Client收到確認(rèn)應(yīng)答后，檢查（確認(rèn)號(hào)）ack是否為x+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=y+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為y+1，ACK是否為1，如果正確則連接建立成功，完成三次握手，隨后Client與Server之間可以開(kāi)始傳輸數(shù)據(jù)了。
3.2.2為什么三次握手中客戶端還要發(fā)送一次確認(rèn)呢？可以二次握手嗎？
三次握手是為了防止，客戶端的請(qǐng)求報(bào)文在網(wǎng)絡(luò)滯留，客戶端超時(shí)重傳了請(qǐng)求報(bào)文，服務(wù)端建立連接，傳輸數(shù)據(jù)，釋放連接之后，服務(wù)器又收到了客戶端滯留的請(qǐng)求報(bào)文，建立連接一直等待客戶端發(fā)送數(shù)據(jù)。
服務(wù)器對(duì)客戶端的請(qǐng)求進(jìn)行回應(yīng)(第二次握手)后，就會(huì)理所當(dāng)然的認(rèn)為連接已建立，而如果客戶端并沒(méi)有收到服務(wù)器的回應(yīng)呢？此時(shí)，客戶端仍認(rèn)為連接未建立，服務(wù)器會(huì)對(duì)已建立的連接保存必要的資源，如果大量的這種情況，服務(wù)器會(huì)崩潰。
兩次不可以：
tcp是全雙工通信，兩次握手只能確定單向數(shù)據(jù)鏈路是可以通信的，并不能保證反向的通信正常
不用四次：
本來(lái)握手應(yīng)該和揮手一樣都是需要確認(rèn)兩個(gè)方向都能聯(lián)通的，本來(lái)模型應(yīng)該是：
1.客戶端發(fā)送syn0給服務(wù)器
2.服務(wù)器收到syn0，回復(fù)ack(syn0+1)
3.服務(wù)器發(fā)送syn1
4.客戶端收到syn1，回復(fù)ack(syn1+1)
因?yàn)閠cp是全雙工的，上邊的四部確認(rèn)了數(shù)據(jù)在兩個(gè)方向上都是可以正確到達(dá)的，但是2，3步?jīng)]有沒(méi)有上下的聯(lián)系，可以將其合并，加快握手效率，所有就變成了3步握手。
3.2.3為什么服務(wù)端易受到SYN攻擊？
服務(wù)器端的資源分配是在二次握手時(shí)分配的，而客戶端的資源是在完成三次握手時(shí)分配的，所以服務(wù)器容易受到SYN洪泛攻擊，SYN攻擊就是Client在短時(shí)間內(nèi)偽造大量不存在的IP地址，并向Server不斷地發(fā)送SYN包，Server則回復(fù)確認(rèn)包，并等待Client確認(rèn)，由于源地址不存在，因此Server需要不斷重發(fā)直至超時(shí)，這些偽造的SYN包將長(zhǎng)時(shí)間占用未連接隊(duì)列，導(dǎo)致正常的SYN請(qǐng)求因?yàn)殛?duì)列滿而被丟棄，從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓。
防范SYN攻擊措施：降低主機(jī)的等待時(shí)間使主機(jī)盡快的釋放半連接的占用，短時(shí)間受到某IP的重復(fù)SYN則丟棄后續(xù)請(qǐng)求。
3.2.4什么是四次揮手
1.數(shù)據(jù)傳輸結(jié)束后，客戶端的應(yīng)用進(jìn)程發(fā)出連接釋放報(bào)文段（FIN），并停止發(fā)送數(shù)據(jù)，客戶端進(jìn)入FIN_WAIT_1狀態(tài)，此時(shí)客戶端依然可以接收服務(wù)器發(fā)送來(lái)的數(shù)據(jù)。
2.服務(wù)器接收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)號(hào)為收到的序列號(hào)+1，服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)?？蛻舳耸盏胶筮M(jìn)入FIN_WAIT_2狀態(tài)。
3.當(dāng)服務(wù)器沒(méi)有數(shù)據(jù)要發(fā)送時(shí)，服務(wù)器發(fā)送一個(gè)FIN報(bào)文，此時(shí)服務(wù)器進(jìn)入LAST_ACK狀態(tài)，等待客戶端的確認(rèn)。
4.客戶端收到服務(wù)器的FIN報(bào)文后，給服務(wù)器發(fā)送一個(gè)ACK報(bào)文，確認(rèn)號(hào)為收到的序列號(hào)+1。此時(shí)客戶端進(jìn)入TIME_WAIT狀態(tài)，等待2MSL（MSL：報(bào)文段最大生存時(shí)間），然后關(guān)閉連接。
3.2.5為什么客戶端最后還要等待2MSL？
2MSL意義：
1、保證最后一次握手報(bào)文能到達(dá)，能進(jìn)行超時(shí)重傳。
2、2MSL后，這次連接的所有報(bào)文都會(huì)消失，不會(huì)影響下一次連接。
3.2.6為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？
因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，“你發(fā)的FIN報(bào)文我收到了”。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手。
————————————————
版權(quán)聲明：本文為CSDN博主「Oliver.H」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43253519/article/details/108351553
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
