計(jì)算機(jī)網(wǎng)絡(luò)太難?了解這一篇就夠了
計(jì)算機(jī)網(wǎng)絡(luò)、計(jì)算機(jī)操作系統(tǒng)這兩個(gè)“兄弟”是所有開發(fā)崗位都需要“結(jié)拜”的,不管你是 Java、C++還是測(cè)試。對(duì)于后端開發(fā)的童鞋來(lái)說(shuō),計(jì)算機(jī)網(wǎng)絡(luò)的重要性不亞于語(yǔ)言基礎(chǔ),畢竟平時(shí)開發(fā)經(jīng)常會(huì)和網(wǎng)絡(luò)打交道,比如:抓個(gè)包等等。所以對(duì)這一塊知識(shí)點(diǎn)的準(zhǔn)備還是要抱著敬畏之心,不要放過(guò)任何一個(gè)漏網(wǎng)之題。下面創(chuàng)新互聯(lián)分享下我的學(xué)習(xí)過(guò)程:
1. 看書:對(duì)于計(jì)算機(jī)比較基礎(chǔ)的模塊,我都是比較推薦找一本經(jīng)典的書籍來(lái)好好學(xué)習(xí)下,不可以只看面經(jīng)就去面試了。我一共看了兩本書:湯小丹的《計(jì)算機(jī)操作系統(tǒng)》和《圖解HTTP》?!队?jì)算機(jī)操作系統(tǒng)》是教科書,所以知識(shí)點(diǎn)相對(duì)比較基礎(chǔ),覆蓋范圍也比較廣,非科班的學(xué)生還是很有必要看一看的?!秷D解HTTP》這本書用很多插圖將一些知識(shí)點(diǎn)講的通俗易懂,看起來(lái)也很快,還是比較推薦的。
2. 做筆記:計(jì)算機(jī)網(wǎng)絡(luò)的知識(shí)點(diǎn)還是比較多的,需要看書的時(shí)候做好筆記,方便復(fù)習(xí)。而且做筆記的時(shí)候可以就這個(gè)知識(shí)點(diǎn)去百度下,看看有沒(méi)有自己遺漏的點(diǎn),再給補(bǔ)充進(jìn)來(lái)。在這里說(shuō)下,我為什么一直強(qiáng)調(diào)做筆記?好處 1:做筆記是第 1 次你對(duì)書中的知識(shí)點(diǎn)的回顧,加深記憶;好處 2:而且如果你是發(fā)表在公關(guān)社區(qū)的肯定要保證大限度的正確性,就需要再去看看這個(gè)知識(shí)點(diǎn),核對(duì)下自己是否有理解偏差和遺漏等,這樣就完成了知識(shí)點(diǎn)的深挖;好處3:正在到面試復(fù)習(xí)的時(shí)候,你是不太可能重新看一本書的,那么筆記就顯得很重要了,自己做的筆記,復(fù)習(xí)起來(lái)很快,而且最好在筆記里能有一些自己區(qū)別于面經(jīng)的理解。
3. 看面經(jīng):經(jīng)常刷一刷??停纯磳?duì)于計(jì)算機(jī)網(wǎng)絡(luò),面試官們都是怎么問(wèn)的?很多問(wèn)題你可能會(huì),但是不懂面試官的問(wèn)法,也會(huì)回答不上來(lái);問(wèn)到的題目自己是否準(zhǔn)備了?而且對(duì)于計(jì)算機(jī)網(wǎng)絡(luò)和計(jì)算機(jī)操作系統(tǒng)會(huì)因?yàn)楣竞蛵徫坏牟煌兴鶄?cè)重的,多看看面經(jīng)就會(huì)發(fā)現(xiàn)還是有一點(diǎn)規(guī)律的,但是這都不是絕對(duì)的,最后還要看面你的面試官的喜好。
學(xué)習(xí)計(jì)算機(jī)網(wǎng)絡(luò)時(shí)我們一般采用折中的辦法,也就是中和 OSI 和 TCP/IP 的優(yōu)點(diǎn),采用一種只有五層協(xié)議的體系結(jié)構(gòu),這樣既簡(jiǎn)潔又能將概念闡述清楚。
應(yīng)用層(application-layer)的任務(wù)是通過(guò)應(yīng)用進(jìn)程間的交互來(lái)完成特定網(wǎng)絡(luò)應(yīng)用。應(yīng)用層協(xié)議定義的是應(yīng)用進(jìn)程(進(jìn)程:
主機(jī)中正在運(yùn)行的程序)間的通信和交互的規(guī)則。對(duì)于不同的網(wǎng)絡(luò)應(yīng)用需要不同的應(yīng)用層協(xié)議。在互聯(lián)網(wǎng)中應(yīng)用層協(xié)議很多,如
域名系統(tǒng) DNS,支持萬(wàn)維網(wǎng)應(yīng)用的 HTTP 協(xié)議,支持電子郵件的 SMTP 協(xié)議等等。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報(bào)文。
運(yùn)輸層(transport layer)的主要任務(wù)就是負(fù)責(zé)向兩臺(tái)
主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。應(yīng)用進(jìn)程利用該服務(wù)傳送應(yīng)用層報(bào)文?!巴ㄓ玫摹笔侵覆⒉会槍?duì)某一個(gè)特定的網(wǎng)絡(luò)應(yīng)用,而是多種應(yīng)用可以使用同一個(gè)運(yùn)輸層服務(wù)。
由于一臺(tái)
主機(jī)可同時(shí)運(yùn)行多個(gè)線程,因此運(yùn)輸層有復(fù)用和分用的功能。所謂復(fù)用就是指多個(gè)應(yīng)用層進(jìn)程可同時(shí)使用下面運(yùn)輸層的服務(wù),分用和復(fù)用相反,是運(yùn)輸層把收到的信息分別交付上面應(yīng)用層中的相應(yīng)進(jìn)程。
在計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)計(jì)算機(jī)之間可能會(huì)經(jīng)過(guò)很多個(gè)數(shù)據(jù)鏈路,也可能還要經(jīng)過(guò)很多通信子網(wǎng)。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點(diǎn), 確保數(shù)據(jù)及時(shí)傳送。在發(fā)送數(shù)據(jù)時(shí),網(wǎng)絡(luò)層把運(yùn)輸層產(chǎn)生的報(bào)文段或用戶數(shù)據(jù)報(bào)封裝成分組和包進(jìn)行傳送。在 TCP / IP 體系結(jié)構(gòu)中,由于網(wǎng)絡(luò)層使用 IP 協(xié)議,因此分組也叫 IP 數(shù)據(jù)報(bào),簡(jiǎn)稱數(shù)據(jù)報(bào)。
數(shù)據(jù)鏈路層(data link layer)通常簡(jiǎn)稱為鏈路層。兩臺(tái)
主機(jī)之間的數(shù)據(jù)傳輸,總是在一段一段的鏈路上傳送的,這就需要使用專門的鏈路層的協(xié)議。在兩個(gè)相鄰節(jié)點(diǎn)之間傳送數(shù)據(jù)時(shí),數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來(lái)的 IP 數(shù)據(jù)報(bào)組裝成幀,在兩個(gè)相鄰節(jié)點(diǎn)間的鏈路上傳送幀。每一幀包括數(shù)據(jù)和必要的控制信息(如:同步信息,地址信息,差錯(cuò)控制等)。
在接收數(shù)據(jù)時(shí),控制信息使接收端能夠知道一個(gè)幀從哪個(gè)比特開始和到哪個(gè)比特結(jié)束。這樣,數(shù)據(jù)鏈路層在收到一個(gè)幀后,就可從中提出數(shù)據(jù)部分,上交給網(wǎng)絡(luò)層??刂菩畔⑦€使接收端能夠檢測(cè)到所收到的幀中有無(wú)差錯(cuò)。如果發(fā)現(xiàn)差錯(cuò),數(shù)據(jù)鏈路層就簡(jiǎn)單地丟棄這個(gè)出了差錯(cuò)的幀,以避免繼續(xù)在網(wǎng)絡(luò)中傳送下去白白浪費(fèi)網(wǎng)絡(luò)資源。如果需要改正數(shù)據(jù)在鏈路層傳輸時(shí)出現(xiàn)差錯(cuò)(這就是說(shuō),數(shù)據(jù)鏈路層不僅要檢錯(cuò),而且還要糾錯(cuò)),那么就要采用可靠性傳輸協(xié)議來(lái)糾正出現(xiàn)的差錯(cuò)。這種方法會(huì)使鏈路層的協(xié)議復(fù)雜些。
在物理層上所傳送的數(shù)據(jù)單位是比特。物理層(physical layer)的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送,盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡(luò)的具體傳輸介質(zhì)是什么?!巴该鱾魉捅忍亓鳌北硎窘?jīng)實(shí)際電路傳送后的比特流沒(méi)有發(fā)生變化,對(duì)傳送的比特流來(lái)說(shuō),這個(gè)電路好像是看不見的。
計(jì)算機(jī)五層網(wǎng)絡(luò)體系中涉及的協(xié)議非常多,下面就常用的做了列舉:
計(jì)算機(jī)網(wǎng)絡(luò)太難?了解這一篇就夠了
網(wǎng)絡(luò)層的 ARP 協(xié)議完成了 IP 地址與物理地址的映射。首先,每臺(tái)
主機(jī)都會(huì)在自己的 ARP 緩沖區(qū)中建立一個(gè) ARP 列表,以表示 IP 地址和 MAC 地址的對(duì)應(yīng)關(guān)系。當(dāng)源
主機(jī)需要將一個(gè)數(shù)據(jù)包要發(fā)送到目的
主機(jī)時(shí),會(huì)首先檢查自己 ARP 列表中是否存在該 IP 地址對(duì)應(yīng)的 MAC 地址:如果有,就直接將數(shù)據(jù)包發(fā)送到這個(gè) MAC 地址;如果沒(méi)有,就向本地網(wǎng)段發(fā)起一個(gè) ARP 請(qǐng)求的廣播包,查詢此目的
主機(jī)對(duì)應(yīng)的 MAC 地址。
此 ARP 請(qǐng)求數(shù)據(jù)包里包括源
主機(jī)的 IP 地址、硬件地址、以及目的
主機(jī)的 IP 地址。網(wǎng)絡(luò)中所有的
主機(jī)收到這個(gè) ARP 請(qǐng)求后,會(huì)檢查數(shù)據(jù)包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此數(shù)據(jù)包;如果相同,該
主機(jī)首先將發(fā)送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中,如果 ARP 表中已經(jīng)存在該 IP 的信息,則將其覆蓋,然后給源
主機(jī)發(fā)送一個(gè) ARP 響應(yīng)數(shù)據(jù)包,告訴對(duì)方自己是它需要查找的 MAC 地址;源
主機(jī)收到這個(gè) ARP 響應(yīng)數(shù)據(jù)包后,將得到的目的
主機(jī)的 IP 地址和 MAC 地址添加到自己的 ARP 列表中,并利用此信息開始數(shù)據(jù)的傳輸。如果源
主機(jī)一直沒(méi)有收到 ARP 響應(yīng)數(shù)據(jù)包,表示 ARP 查詢失敗。
IP 地址是指互聯(lián)網(wǎng)協(xié)議地址,是 IP 協(xié)議提供的一種統(tǒng)一的地址格式,它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺(tái)
主機(jī)分配一個(gè)邏輯地址,以此來(lái)屏蔽物理地址的差異。IP 地址編址方案將 IP 地址
空間劃分為 A、B、C、D、E 五類,其中 A、B、C 是基本類,D、E 類作為多播和保留使用,為特殊地址。
每個(gè) IP 地址包括兩個(gè)標(biāo)識(shí)碼(ID),即網(wǎng)絡(luò) ID 和
主機(jī) ID。同一個(gè)物理網(wǎng)絡(luò)上的所有
主機(jī)都使用同一個(gè)網(wǎng)絡(luò) ID,網(wǎng)絡(luò)上的一個(gè)
主機(jī)(包括網(wǎng)絡(luò)上工作站,服務(wù)器和路由器等)有一個(gè)
主機(jī) ID 與其對(duì)應(yīng)。A~E 類地址的特點(diǎn)如下:
A 類地址:以 0 開頭,第一個(gè)字節(jié)范圍:0~127;
B 類地址:以 10 開頭,第一個(gè)字節(jié)范圍:128~191;
C 類地址:以 110 開頭,第一個(gè)字節(jié)范圍:192~223;
D 類地址:以 1110 開頭,第一個(gè)字節(jié)范圍為 224~239;
E 類地址:以 1111 開頭,保留地址
1. TCP 是面向連接的。(就好像打電話一樣,通話前需要先撥號(hào)建立連接,通話結(jié)束后要掛機(jī)釋放連接);
2. 每一條 TCP 連接只能有兩個(gè)端點(diǎn),每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的(一對(duì)一);
3. TCP 提供可靠交付的服務(wù)。通過(guò) TCP 連接傳送的數(shù)據(jù),無(wú)差錯(cuò)、不丟失、不重復(fù)、并且按序到達(dá);
4. TCP 提供全雙工通信。TCP 允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存,用來(lái)臨時(shí)存放雙方通信的數(shù)據(jù);
5. 面向字節(jié)流。TCP 中的“流”(Stream)指的是流入進(jìn)程或從進(jìn)程流出的字節(jié)序列?!懊嫦蜃止?jié)流”的含義是:雖然應(yīng)用程序和 TCP 的交互是一次一個(gè)數(shù)據(jù)塊(大小不等),但 TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。
1. UDP 是無(wú)連接的;
2. UDP 使用盡大努力交付,即不保證可靠交付,因此
主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)(這里面有許多參數(shù));
3. UDP 是面向報(bào)文的;
4. UDP 沒(méi)有擁塞控制,因此網(wǎng)絡(luò)出現(xiàn)擁塞不會(huì)使源
主機(jī)的發(fā)送速率降低(對(duì)實(shí)時(shí)應(yīng)用很有用,如 直播,實(shí)時(shí)視頻會(huì)議等);
5. UDP 支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信;
6. UDP 的首部開銷小,只有 8 個(gè)字節(jié),比 TCP 的 20 個(gè)字節(jié)的首部要短。
TCP 提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接,數(shù)據(jù)傳送結(jié)束后要釋放連接。TCP 不提供廣播或多播服務(wù)。由于 TCP 要提供可靠的,面向連接的運(yùn)輸服務(wù)(TCP 的可靠體現(xiàn)在 TCP 在傳遞數(shù)據(jù)之前,會(huì)有三次握手來(lái)建立連接,而且在數(shù)據(jù)傳遞時(shí),有確認(rèn)、窗口、重傳、擁塞控制機(jī)制,在數(shù)據(jù)傳完后,還會(huì)斷開連接用來(lái)節(jié)約系統(tǒng)資源),這難以避免增加了許多開銷,如確認(rèn),流量控制,計(jì)時(shí)器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多,還要占用許多處理機(jī)資源。
UDP 在傳送數(shù)據(jù)之前不需要先建立連接,遠(yuǎn)地
主機(jī)在收到 UDP 報(bào)文后,不需要給出任何確認(rèn)。雖然 UDP 不提供可靠交付,但在某些情況下 UDP 確是一種最有效的工作方式(一般用于即時(shí)通信),比如:QQ 語(yǔ)音、 QQ 視頻 、直播等等。
FTP:定義了文件傳輸協(xié)議,使用 21 端口。常說(shuō)某某計(jì)算機(jī)開了 FTP 服務(wù)便是啟動(dòng)了文件傳輸服務(wù)。下載文件,上傳主頁(yè),都要用到 FTP 服務(wù)。
Telnet:它是一種用于遠(yuǎn)程登陸的端口,用戶可以以自己的身份遠(yuǎn)程連接到計(jì)算機(jī)上,通過(guò)這種端口可以提供一種基于 DOS 模式下的通信服務(wù)。如以前的 BBS 是-純字符界面的,支持 BBS 的服務(wù)器將 23 端口打開,對(duì)外提供服務(wù)。
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)收信)。
HTTP:從 Web 服務(wù)器傳輸超文本到本地瀏覽器的傳送協(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ù)。
TCP 建立連接的過(guò)程叫做握手,握手需要在客戶和服務(wù)器之間交換三個(gè) TCP 報(bào)文段。
計(jì)算機(jī)網(wǎng)絡(luò)太難?了解這一篇就夠了
最初客戶端和服務(wù)端都處于 CLOSED(關(guān)閉) 狀態(tài)。本例中 A(Client) 主動(dòng)打開連接,B(Server) 被動(dòng)打開連接。
一開始,B 的 TCP 服務(wù)器進(jìn)程首先創(chuàng)建傳輸控制塊TCB,準(zhǔn)備接受客戶端進(jìn)程的連接請(qǐng)求。然后服務(wù)端進(jìn)程就處于 LISTEN(監(jiān)聽) 狀態(tài),等待客戶端的連接請(qǐng)求。如有,立即作出響應(yīng)。
第一次握手:A 的 TCP 客戶端進(jìn)程也是首先創(chuàng)建傳輸控制塊 TCB。然后,在打算建立 TCP 連接時(shí),向 B 發(fā)出連接請(qǐng)求報(bào)文段,這時(shí)首部中的同步位 SYN=1,同時(shí)選擇一個(gè)初始序號(hào) seq = x。TCP 規(guī)定,SYN 報(bào)文段(即 SYN = 1 的報(bào)文段)不能攜帶數(shù)據(jù),但要消耗掉一個(gè)序號(hào)。這時(shí),TCP 客戶進(jìn)程進(jìn)入 SYN-SENT(同步已發(fā)送)狀態(tài)。
第二次握手:B 收到連接請(qǐng)求報(bào)文后,如果同意建立連接,則向 A 發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中應(yīng)把 SYN 位和 ACK 位都置 1,確認(rèn)號(hào)是 ack = x + 1,同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y。請(qǐng)注意,這個(gè)報(bào)文段也不能攜帶數(shù)據(jù),但同樣要消耗掉一個(gè)序號(hào)。這時(shí) TCP 服務(wù)端進(jìn)程進(jìn)入 SYN-RCVD(同步收到)狀態(tài)。
第三次握手:TCP 客戶進(jìn)程收到 B 的確認(rèn)后,還要向 B 給出確認(rèn)。確認(rèn)報(bào)文段的 ACK 置 1,確認(rèn)號(hào) ack = y + 1,而自己的序號(hào) seq = x + 1。這時(shí) ACK 報(bào)文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號(hào),這種情況下,下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是 seq = x + 1。這時(shí),TCP 連接已經(jīng)建立,A 進(jìn)入 ESTABLISHED(已建立連接)狀態(tài)。
為了防止已經(jīng)失效的連接請(qǐng)求報(bào)文段突然又傳送到了 B,因而產(chǎn)生錯(cuò)誤。比如下面這種情況:A 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失,而是在網(wǎng)路結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了,以致于延誤到連接釋放以后的某個(gè)時(shí)間段才到達(dá) B。本來(lái)這是一個(gè)早已失效的報(bào)文段。但是 B 收到此失效的鏈接請(qǐng)求報(bào)文段后,就誤認(rèn)為 A 又發(fā)出一次新的連接請(qǐng)求。于是就向 A 發(fā)出確認(rèn)報(bào)文段,同意建立連接。
對(duì)于上面這種情況,如果不進(jìn)行第三次握手,B 發(fā)出確認(rèn)后就認(rèn)為新的運(yùn)輸連接已經(jīng)建立了,并一直等待 A 發(fā)來(lái)數(shù)據(jù)。B 的許多資源就這樣白白浪費(fèi)了。
如果采用了三次握手,由于 A 實(shí)際上并沒(méi)有發(fā)出建立連接請(qǐng)求,所以不會(huì)理睬 B 的確認(rèn),也不會(huì)向 B 發(fā)送數(shù)據(jù)。B 由于收不到確認(rèn),就知道 A 并沒(méi)有要求建立連接。
有人可能會(huì)說(shuō) A 發(fā)出第三次握手的信息后在沒(méi)有接收到 B 的請(qǐng)求就已經(jīng)進(jìn)入了連接狀態(tài),那如果 A 的這個(gè)確認(rèn)包丟失或者滯留了怎么辦?
我們需要明白一點(diǎn),完全可靠的通信協(xié)議是不存在的。在經(jīng)過(guò)三次握手之后,客戶端和服務(wù)端已經(jīng)可以確認(rèn)之前的通信狀況,都收到了確認(rèn)信息。所以即便再增加握手次數(shù)也不能保證后面的通信完全可靠,所以是沒(méi)有必要的。
接收端傳回發(fā)送端所發(fā)送的 SYN 是為了告訴發(fā)送端,我接收到的信息確實(shí)就是你所發(fā)送的信號(hào)了。
SYN 是 TCP / IP 建立連接時(shí)使用的握手信號(hào)。在客戶機(jī)和服務(wù)器之間建立正常的 TCP 網(wǎng)絡(luò)連接時(shí),客戶機(jī)首先發(fā)出一個(gè) SYN 消息,服務(wù)器使用 SYN-ACK 應(yīng)答表示接收到了這個(gè)消息,最后客戶機(jī)再以 ACK(Acknowledgement[漢譯:確認(rèn)字符,在數(shù)據(jù)通信傳輸中,接收站發(fā)給發(fā)送站的一種傳輸控制字符。它表示確認(rèn)發(fā)來(lái)的數(shù)據(jù)已經(jīng)接受無(wú)誤])消息響應(yīng)。這樣在客戶機(jī)和服務(wù)器之間才能建立起可靠的 TCP 連接,數(shù)據(jù)才可以在客戶機(jī)和服務(wù)器之間傳遞。
雙方通信無(wú)誤必須是兩者互相發(fā)送信息都無(wú)誤。傳了 SYN,證明發(fā)送方到接收方的通道沒(méi)有問(wèn)題,但是接收方到發(fā)送方的通道還需要 ACK 信號(hào)來(lái)進(jìn)行驗(yàn)證。
據(jù)傳輸結(jié)束后,通信的雙方都可以釋放連接?,F(xiàn)在 A 和 B 都處于 ESTABLISHED 狀態(tài)。
計(jì)算機(jī)網(wǎng)絡(luò)太難?了解這一篇就夠了
第一次揮手:A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段,并停止再發(fā)送數(shù)據(jù),主動(dòng)關(guān)閉 TCP 連接。A 把連接釋放報(bào)文段首部的終止控制位 FIN 置 1,其序號(hào) seq = u(等于前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加 1),這時(shí) A 進(jìn)入 FIN-WAIT-1(終止等待1)狀態(tài),等待 B 的確認(rèn)。請(qǐng)注意:TCP 規(guī)定,F(xiàn)IN 報(bào)文段即使不攜帶數(shù)據(jù),也將消耗掉一個(gè)序號(hào)。
第二次揮手:B 收到連接釋放報(bào)文段后立即發(fā)出確認(rèn),確認(rèn)號(hào)是 ack = u + 1,而這個(gè)報(bào)文段自己的序號(hào)是 v(等于 B 前面已經(jīng)傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1),然后 B 就進(jìn)入 CLOSE-WAIT(關(guān)閉等待)狀態(tài)。TCP 服務(wù)端進(jìn)程這時(shí)應(yīng)通知高層應(yīng)用進(jìn)程,因而從 A 到 B 這個(gè)方向的連接就釋放了,這時(shí)的 TCP 連接處于半關(guān)閉(half-close)狀態(tài),即 A 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了,但 B 若發(fā)送數(shù)據(jù),A 仍要接收。也就是說(shuō),從 B 到 A 這個(gè)方向的連接并未關(guān)閉,這個(gè)狀態(tài)可能會(huì)持續(xù)一段時(shí)間。A 收到來(lái)自 B 的確認(rèn)后,就進(jìn)入 FIN-WAIT-2(終止等待2)狀態(tài),等待 B 發(fā)出的連接釋放報(bào)文段。
第三次揮手:若 B 已經(jīng)沒(méi)有要向 A 發(fā)送的數(shù)據(jù),其應(yīng)用進(jìn)程就通知 TCP 釋放連接。這時(shí) B 發(fā)出的連接釋放報(bào)文段必須使 FIN = 1。假定 B 的序號(hào)為 w(在半關(guān)閉狀態(tài),B 可能又發(fā)送了一些數(shù)據(jù))。B 還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào) ack = u + 1。這時(shí) B 就進(jìn)入 LAST-ACK(最后確認(rèn))狀態(tài),等待 A 的確認(rèn)。
第四次揮手:A 在收到 B 的連接釋放報(bào)文后,必須對(duì)此發(fā)出確認(rèn)。在確認(rèn)報(bào)文段中把 ACK 置 1,確認(rèn)號(hào) ack = w + 1,而自己的序號(hào) seq = u + 1(前面發(fā)送的 FIN 報(bào)文段要消耗一個(gè)序號(hào))。然后進(jìn)入 TIME-WAIT(時(shí)間等待) 狀態(tài)。請(qǐng)注意,現(xiàn)在 TCP 連接還沒(méi)有釋放掉。必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間 2MSL(MSL:最長(zhǎng)報(bào)文段壽命)后,A 才能進(jìn)入到 CLOSED 狀態(tài),然后撤銷傳輸控制塊,結(jié)束這次 TCP 連接。當(dāng)然如果 B 一收到 A 的確認(rèn)就進(jìn)入 CLOSED 狀態(tài),然后撤銷傳輸控制塊。所以在釋放連接時(shí),B 結(jié)束 TCP 連接的時(shí)間要早于 A。
1. 為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。這個(gè) ACK 報(bào)文段有可能丟失,因而使處在 LAST-ACK 狀態(tài)的 B 收不到對(duì)已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會(huì)超時(shí)重傳這個(gè) FIN+ACK 報(bào)文段,而 A 就能在 2MSL 時(shí)間內(nèi)(超時(shí) + 1MSL 傳輸)收到這個(gè)重傳的 FIN+ACK 報(bào)文段。接著 A 重傳一次確認(rèn),重新啟動(dòng) 2MSL 計(jì)時(shí)器。最后,A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間,而是在發(fā)送完 ACK 報(bào)文段后立即釋放連接,那么就無(wú)法收到 B 重傳的 FIN + ACK 報(bào)文段,因而也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段,這樣,B 就無(wú)法按照正常步驟進(jìn)入 CLOSED 狀態(tài)。
2. 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后,再經(jīng)過(guò)時(shí)間 2MSL,就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。
當(dāng)服務(wù)器執(zhí)行第二次揮手之后, 此時(shí)證明客戶端不會(huì)再向服務(wù)端請(qǐng)求任何數(shù)據(jù), 但是服務(wù)端可能還正在給客戶端發(fā)送數(shù)據(jù)(可能是客戶端上一次請(qǐng)求的資源還沒(méi)有發(fā)送完畢),所以此時(shí)服務(wù)端會(huì)等待把之前未傳輸完的數(shù)據(jù)傳輸完畢之后再發(fā)送關(guān)閉請(qǐng)求。
除時(shí)間等待計(jì)時(shí)器外,TCP 還有一個(gè)?;钣?jì)時(shí)器(keepalive timer)。設(shè)想這樣的場(chǎng)景:客戶已主動(dòng)與服務(wù)器建立了 TCP 連接。但后來(lái)客戶端的
主機(jī)突然發(fā)生故障。顯然,服務(wù)器以后就不能再收到客戶端發(fā)來(lái)的數(shù)據(jù)。因此,應(yīng)當(dāng)有措施使服務(wù)器不要再白白等待下去。這就需要使用保活計(jì)時(shí)器了。
服務(wù)器每收到一次客戶的數(shù)據(jù),就重新設(shè)置?;钣?jì)時(shí)器,時(shí)間的設(shè)置通常是兩個(gè)小時(shí)。若兩個(gè)小時(shí)都沒(méi)有收到客戶端的數(shù)據(jù),服務(wù)端就發(fā)送一個(gè)探測(cè)報(bào)文段,以后則每隔 75 秒鐘發(fā)送一次。若連續(xù)發(fā)送 10個(gè) 探測(cè)報(bào)文段后仍然無(wú)客戶端的響應(yīng),服務(wù)端就認(rèn)為客戶端出了故障,接著就關(guān)閉這個(gè)連接。
1. 數(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ù);
2. 對(duì)失序數(shù)據(jù)包重排序:既然 TCP 報(bào)文段作為 IP 數(shù)據(jù)報(bào)來(lái)傳輸,而 IP 數(shù)據(jù)報(bào)的到達(dá)可能會(huì)失序,因此 TCP 報(bào)文段的到達(dá)也可能會(huì)失序。TCP 將對(duì)失序數(shù)據(jù)進(jìn)行重新排序,然后才交給應(yīng)用層;
3. 丟棄重復(fù)數(shù)據(jù):對(duì)于重復(fù)數(shù)據(jù),能夠丟棄重復(fù)數(shù)據(jù);
4. 應(yīng)答機(jī)制:當(dāng) TCP 收到發(fā)自 TCP 連接另一端的數(shù)據(jù),它將發(fā)送一個(gè)確認(rèn)。這個(gè)確認(rèn)不是立即發(fā)送,通常將推遲幾分之一秒;
5. 超時(shí)重發(fā):當(dāng) TCP 發(fā)出一個(gè)段后,它啟動(dòng)一個(gè)定時(shí)器,等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn),將重發(fā)這個(gè)報(bào)文段;
6. 流量控制:TCP 連接的每一方都有固定大小的緩沖
空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù),這可以防止較快
主機(jī)致使較慢
主機(jī)的緩沖區(qū)溢出,這就是流量控制。TCP 使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。
停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)?,它的基本原理就是每發(fā)完一個(gè)分組就停止發(fā)送,等待對(duì)方確認(rèn)。在收到確認(rèn)后再發(fā)下一個(gè)分組;在停止等待協(xié)議中,若接收方收到重復(fù)分組,就丟棄該分組,但同時(shí)還要發(fā)送確認(rèn)。主要包括以下幾種情況:無(wú)差錯(cuò)情況、出現(xiàn)差錯(cuò)情況(超時(shí)重傳)、確認(rèn)丟失和確認(rèn)遲到、確認(rèn)丟失和確認(rèn)遲到。
停止等待協(xié)議中超時(shí)重傳是指只要超過(guò)一段時(shí)間仍然沒(méi)有收到確認(rèn),就重傳前面發(fā)送過(guò)的分組(認(rèn)為剛才發(fā)送過(guò)的分組丟失了)。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器,其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些。這種自動(dòng)重傳方式常稱為自動(dòng)重傳請(qǐng)求 ARQ。
連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口,凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去,而不需要等待對(duì)方確認(rèn)。接收方一般采用累計(jì)確認(rèn),對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn),表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。
TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制的機(jī)制。滑動(dòng)窗口(Sliding window)是一種流量控制技術(shù)。早期的網(wǎng)絡(luò)通信中,通信雙方不會(huì)考慮網(wǎng)絡(luò)的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡(luò)擁塞狀況,同時(shí)發(fā)送數(shù)據(jù),導(dǎo)致中間節(jié)點(diǎn)阻塞掉包,誰(shuí)也發(fā)不了數(shù)據(jù),所以就有了滑動(dòng)窗口機(jī)制來(lái)解決此問(wèn)題。
TCP 中采用滑動(dòng)窗口來(lái)進(jìn)行傳輸控制,滑動(dòng)窗口的大小意味著接收方還有多大的緩沖區(qū)可以用于接收數(shù)據(jù)。發(fā)送方可以通過(guò)滑動(dòng)窗口的大小來(lái)確定應(yīng)該發(fā)送多少字節(jié)的數(shù)據(jù)。當(dāng)滑動(dòng)窗口為 0 時(shí),發(fā)送方一般不能再發(fā)送數(shù)據(jù)報(bào),但有兩種情況除外,一種情況是可以發(fā)送緊急數(shù)據(jù),例如,允許用戶終止在遠(yuǎn)端機(jī)上的運(yùn)行進(jìn)程。另一種情況是發(fā)送方可以發(fā)送一個(gè) 1 字節(jié)的數(shù)據(jù)報(bào)來(lái)通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動(dòng)窗口大小。
TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率,保證接收方來(lái)得及接收。接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來(lái)控制發(fā)送方窗口大小,從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0,則發(fā)送方不能發(fā)送數(shù)據(jù)。
擁塞控制和流量控制不同,前者是一個(gè)全局性的過(guò)程,而后者指點(diǎn)對(duì)點(diǎn)通信量的控制。在某段時(shí)間,若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分,網(wǎng)絡(luò)的性能就要變壞。這種情況就叫擁塞。
擁塞控制就是為了防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中,這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不致于過(guò)載。擁塞控制所要做的都有一個(gè)前提,就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。擁塞控制是一個(gè)全局性的過(guò)程,涉及到所有的
主機(jī),所有的路由器,以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。相反,流量控制往往是點(diǎn)對(duì)點(diǎn)通信量的控制,是個(gè)端到端的問(wèn)題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率,以便使接收端來(lái)得及接收。
為了進(jìn)行擁塞控制,TCP 發(fā)送方要維持一個(gè)擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡(luò)的擁塞程度,并且動(dòng)態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個(gè)。
TCP 的擁塞控制采用了四種算法,即:慢開始、擁塞避免、快重傳和快恢復(fù)。在網(wǎng)絡(luò)層也可以使路由器采用適當(dāng)?shù)姆纸M丟棄策略(如:主動(dòng)隊(duì)列管理 AQM),以減少網(wǎng)絡(luò)擁塞的發(fā)生。
慢開始算法的思路是當(dāng)
主機(jī)開始發(fā)送數(shù)據(jù)時(shí),如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò),那么可能會(huì)引起網(wǎng)絡(luò)阻塞,因?yàn)楝F(xiàn)在還不知道網(wǎng)絡(luò)的符合情況。經(jīng)驗(yàn)表明,較好的方法是先探測(cè)一下,即由小到大逐漸增大發(fā)送窗口,也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd 初始值為 1,每經(jīng)過(guò)一個(gè)傳播輪次,cwnd 加倍。
擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢增大,即每經(jīng)過(guò)一個(gè)往返時(shí)間 RTT 就把發(fā)送方的 cwnd 加 1。
在 TCP/IP 中,快速重傳和快恢復(fù)(fast retransmit and recovery,F(xiàn)RR)是一種擁塞控制算法,它能快速恢復(fù)丟失的數(shù)據(jù)包。
沒(méi)有 FRR,如果數(shù)據(jù)包丟失了,TCP 將會(huì)使用定時(shí)器來(lái)要求傳輸暫停。在暫停的這段時(shí)間內(nèi),沒(méi)有新的或復(fù)制的數(shù)據(jù)包被發(fā)送。有了 FRR,如果接收機(jī)接收到一個(gè)不按順序的數(shù)據(jù)段,它會(huì)立即給發(fā)送機(jī)發(fā)送一個(gè)重復(fù)確認(rèn)。如果發(fā)送機(jī)接收到三個(gè)重復(fù)確認(rèn),它會(huì)假定確認(rèn)件指出的數(shù)據(jù)段丟失了,并立即重傳這些丟失的數(shù)據(jù)段。
有了 FRR,就不會(huì)因?yàn)橹貍鲿r(shí)要求的暫停被耽誤。當(dāng)有單獨(dú)的數(shù)據(jù)包丟失時(shí),快速重傳和快恢復(fù)(FRR)能最有效地工作。當(dāng)有多個(gè)數(shù)據(jù)信息包在某一段很短的時(shí)間內(nèi)丟失時(shí),它則不能很有效地工作。
在進(jìn)行 Java NIO 學(xué)習(xí)時(shí),可能會(huì)發(fā)現(xiàn):如果客戶端連續(xù)不斷的向服務(wù)端發(fā)送數(shù)據(jù)包時(shí),服務(wù)端接收的數(shù)據(jù)會(huì)出現(xiàn)兩個(gè)數(shù)據(jù)包粘在一起的情況。
1. TCP 是基于字節(jié)流的,雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊,但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無(wú)結(jié)構(gòu)的字節(jié)流,沒(méi)有邊界;
2. 從 TCP 的幀結(jié)構(gòu)也可以看出,在 TCP 的首部沒(méi)有表示數(shù)據(jù)長(zhǎng)度的字段。
基于上面兩點(diǎn),在使用 TCP 傳輸數(shù)據(jù)時(shí),才有粘包或者拆包現(xiàn)象發(fā)生的可能。一個(gè)數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個(gè)數(shù)據(jù)包的信息,這種現(xiàn)象即為粘包。
接收端收到了兩個(gè)數(shù)據(jù)包,但是這兩個(gè)數(shù)據(jù)包要么是不完整的,要么就是多出來(lái)一塊,這種情況即發(fā)生了拆包和粘包。拆包和粘包的問(wèn)題導(dǎo)致接收端在處理的時(shí)候會(huì)非常困難,因?yàn)闊o(wú)法區(qū)分一個(gè)完整的數(shù)據(jù)包。
采用 TCP 協(xié)議傳輸數(shù)據(jù)的客戶端與服務(wù)器經(jīng)常是保持一個(gè)長(zhǎng)連接的狀態(tài)(一次連接發(fā)一次數(shù)據(jù)不存在粘包),雙方在連接不斷開的情況下,可以一直傳輸數(shù)據(jù)。但當(dāng)發(fā)送的數(shù)據(jù)包過(guò)于的小時(shí),那么 TCP 協(xié)議默認(rèn)的會(huì)啟用 Nagle 算法,將這些較小的數(shù)據(jù)包進(jìn)行合并發(fā)送(緩沖區(qū)數(shù)據(jù)發(fā)送是一個(gè)堆壓的過(guò)程);這個(gè)合并過(guò)程就是在發(fā)送緩沖區(qū)中進(jìn)行的,也就是說(shuō)數(shù)據(jù)發(fā)送出來(lái)它已經(jīng)是粘包的狀態(tài)了。
接收方采用 TCP 協(xié)議接收數(shù)據(jù)時(shí)的過(guò)程是這樣的:數(shù)據(jù)到接收方,從網(wǎng)絡(luò)模型的下方傳遞至傳輸層,傳輸層的 TCP 協(xié)議處理是將其放置接收緩沖區(qū),然后由應(yīng)用層來(lái)主動(dòng)獲?。– 語(yǔ)言用 recv、read 等函數(shù));這時(shí)會(huì)出現(xiàn)一個(gè)問(wèn)題,就是我們?cè)诔绦蛑姓{(diào)用的讀取數(shù)據(jù)函數(shù)不能及時(shí)的把緩沖區(qū)中的數(shù)據(jù)拿出來(lái),而下一個(gè)數(shù)據(jù)又到來(lái)并有一部分放入的緩沖區(qū)末尾,等我們讀取數(shù)據(jù)時(shí)就是一個(gè)粘包。(放數(shù)據(jù)的速度 > 應(yīng)用層拿數(shù)據(jù)速度)
分包機(jī)制一般有兩個(gè)通用的解決方法:
1. 特殊字符控制;
2. 在包頭首都添加數(shù)據(jù)包的長(zhǎng)度。
如果使用 netty 的話,就有專門的編碼器和解碼器解決拆包和粘包問(wèn)題了。
tips:UDP 沒(méi)有粘包問(wèn)題,但是有丟包和亂序。不完整的包是不會(huì)有的,收到的都是完全正確的包。傳送的數(shù)據(jù)單位協(xié)議是 UDP 報(bào)文或用戶數(shù)據(jù)報(bào),發(fā)送的時(shí)候既不合并,也不拆分。
1. 100 Continue :表明到目前為止都很正常,客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)。
1. 200 OK
2. 204 No Content :請(qǐng)求已經(jīng)成功處理,但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息,而不需要返回?cái)?shù)據(jù)時(shí)使用。
3. 206 Partial Content :表示客戶端進(jìn)行了范圍請(qǐng)求,響應(yīng)報(bào)文包含由 Content-Range 指定范圍的實(shí)體內(nèi)容。
1. 301 Moved Permanently :永久性重定向;
2. 302 Found :臨時(shí)性重定向;
3. 303 See Other :和 302 有著相同的功能,但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源。
4. 304 Not Modified :如果請(qǐng)求報(bào)文首部包含一些條件,例如:If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,如果不滿足條件,則服務(wù)器會(huì)返回 304 狀態(tài)碼。
5. 307 Temporary Redirect :臨時(shí)重定向,與 302 的含義類似,但是 307 要求瀏覽器不會(huì)把重定向請(qǐng)求的 POST 方法改成 GET 方法。
1. 400 Bad Request :請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤。
2. 401 Unauthorized :該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息(BASIC 認(rèn)證、DIGEST 認(rèn)證)。如果之前已進(jìn)行過(guò)一次請(qǐng)求,則表示用戶認(rèn)證失敗。
3. 403 Forbidden :請(qǐng)求被拒絕。
4. 404 Not Found
1. 500 Internal Server Error :服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤;
2. 503 Service Unavailable :服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù),現(xiàn)在無(wú)法處理請(qǐng)求。
301,302 都是 HTTP 狀態(tài)的編碼,都代表著某個(gè) URL 發(fā)生了轉(zhuǎn)移。
301 redirect: 301 代表永久性轉(zhuǎn)移(Permanently Moved)
302 redirect: 302 代表暫時(shí)性轉(zhuǎn)移(Temporarily Moved)
Forward 和 Redirect 代表了兩種請(qǐng)求轉(zhuǎn)發(fā)方式:直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)。
直接轉(zhuǎn)發(fā)方式(Forward):客戶端和瀏覽器只發(fā)出一次請(qǐng)求,Servlet、HTML、JSP 或其它信息資源,由第二個(gè)信息資源響應(yīng)該請(qǐng)求,在請(qǐng)求對(duì)象 request 中,保存的對(duì)象對(duì)于每個(gè)信息資源是共享的。
間接轉(zhuǎn)發(fā)方式(Redirect):實(shí)際是兩次 HTTP 請(qǐng)求,服務(wù)器端在響應(yīng)第一次請(qǐng)求的時(shí)候,讓瀏覽器再向另外一個(gè) URL 發(fā)出請(qǐng)求,從而達(dá)到轉(zhuǎn)發(fā)的目的。
直接轉(zhuǎn)發(fā)就相當(dāng)于:“A 找 B 借錢,B 說(shuō)沒(méi)有,B 去找 C 借,借到借不到都會(huì)把消息傳遞給 A”;
間接轉(zhuǎn)發(fā)就相當(dāng)于:"A 找 B 借錢,B 說(shuō)沒(méi)有,讓 A 去找 C 借"。
客戶端發(fā)送的 請(qǐng)求報(bào)文 第一行為請(qǐng)求行,包含了方法字段。
1. GET:獲取資源,當(dāng)前網(wǎng)絡(luò)中絕大部分使用的都是 GET;
2. HEAD:獲取報(bào)文首部,和 GET 方法類似,但是不返回報(bào)文實(shí)體主體部分;
3. POST:傳輸實(shí)體主體
4. PUT:上傳文件,由于自身不帶驗(yàn)證機(jī)制,任何人都可以上傳文件,因此存在安全性問(wèn)題,一般不使用該方法。
5. PATCH:對(duì)資源進(jìn)行部分修改。PUT 也可以用于修改資源,但是只能完全替代原始資源,PATCH 允許部分修改。
6. OPTIONS:查詢指定的 URL 支持的方法;
7. CONNECT:要求在與代理服務(wù)器通信時(shí)建立隧道。使用
ssl(Secure Sockets Layer,安全套接層)和 TLS(Transport Layer Security,傳輸層安全)協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。
8. TRACE:追蹤路徑。服務(wù)器會(huì)將通信路徑返回給客戶端。發(fā)送請(qǐng)求時(shí),在 Max-Forwards 首部字段中填入數(shù)值,每經(jīng)過(guò)一個(gè)服務(wù)器就會(huì)減 1,當(dāng)數(shù)值為 0 時(shí)就停止傳輸。通常不會(huì)使用 TRACE,并且它容易受到 XST 攻擊(Cross-Site Tr
分享標(biāo)題:計(jì)算機(jī)網(wǎng)絡(luò)太難?了解這一篇就夠了
標(biāo)題來(lái)源:http://muchs.cn/news35/99035.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站設(shè)計(jì)、用戶體驗(yàn)、網(wǎng)站排名、企業(yè)網(wǎng)站制作、自適應(yīng)網(wǎng)站、面包屑導(dǎo)航
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源:
創(chuàng)新互聯(lián)