免费观看又色又爽又黄的小说免费_美女福利视频国产片_亚洲欧美精品_美国一级大黄大色毛片

計算機網絡太難？了解這一篇就夠了

2021-02-04    分類： 網站建設

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

分享標題：計算機網絡太難？了解這一篇就夠了
標題來源：http://m.newbst.com/news35/99035.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網站設計、用戶體驗、網站排名、企業(yè)網站制作、自適應網站、面包屑導航

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

微信小程序開發(fā)