計算機(jī)網(wǎng)絡(luò)基礎(chǔ)

1七層模型

注意TCP/IP協(xié)議簇在表示層和會話層是沒有協(xié)議的

[圖片上傳失敗...(image-6586a1-1612791064902)].jpg)

  • 物理層：通過物理介質(zhì)傳輸比特流， 數(shù)模轉(zhuǎn)換和模數(shù)轉(zhuǎn)換
  • 數(shù)據(jù)鏈路層：將比特組合成幀,使用鏈路層地址 (以太網(wǎng)使用MAC地址)來訪問介質(zhì),并進(jìn)行差錯檢測。
    • 錯誤檢測和糾正，確保數(shù)據(jù)傳輸?shù)目煽啃裕瑢⒈忍財?shù)據(jù)組成了幀，交換機(jī)工作在這層，對幀解碼，根據(jù)幀中的數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)接收方
  • 網(wǎng)絡(luò)層：IP尋址找到目標(biāo)節(jié)點選擇最佳路徑來建立兩個主機(jī)之間的連接
  • 傳輸層：傳輸層建立了主機(jī)端到端的鏈接，傳輸層的作用是為上層協(xié)議提供端到端的可靠和透明的數(shù)據(jù)傳輸服務(wù)，包括處理差錯控制和流量控制等問題。
  • 應(yīng)用層：為用戶直接提供各種網(wǎng)絡(luò)服務(wù)

數(shù)據(jù)鏈路層的差錯檢測的目的是做到"無比特差錯"
運輸層的差錯檢測的目的是做到"無傳輸差錯"

數(shù)據(jù)鏈路層的差錯檢測是早起的不可靠信道導(dǎo)致

首先，我們需要知道，我們程序的數(shù)據(jù)首先會打到TCP的Segment中，然后TCP的Segment會打到IP的Packet中，然后再打到以太網(wǎng)Ethernet的Frame中，傳到對端后，各個層解析自己的協(xié)議，然后把數(shù)據(jù)交給更高層的協(xié)議處理。

2 TCP

image

注意：

  • TCP的包是沒有IP地址的，那是IP層上的事。但是有源端口和目標(biāo)端口。
  • 一個TCP連接需要四個元組來表示是同一個連接（src_ip, src_port, dst_ip, dst_port）準(zhǔn)確說是五元組，還有一個是協(xié)議。但因為這里只是說TCP協(xié)議，所以，這里我只說四元組。

三次握手

IP是無連接的，不會占用兩個計算機(jī)之間的通信線路，IP分包，不可靠

image

在建立連接之前，服務(wù)器先創(chuàng)建TCB（傳輸控制塊），準(zhǔn)備接受客戶進(jìn)程的連接請求，處于LISTEN（監(jiān)聽）狀態(tài)

A首先創(chuàng)建TCB，然后向B發(fā)出連接請求，SYN置1，同時選擇初始序號seq=x，進(jìn)入SYN-SEND（同步已發(fā)送）狀態(tài)

  • syn_sent
  • syn_rcvd

為什么要三次握手

  • 主要是確認(rèn)序號
  • 次要節(jié)省資源
  1. 為了實現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個序列號， 以標(biāo)識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 并確認(rèn)對方已經(jīng)收到了序列號起始值的必經(jīng)步驟。如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號能被確認(rèn)， 另一方選擇的序列號則得不到確認(rèn)
  2. 如果采用兩次握手，那么只要服務(wù)器發(fā)出確認(rèn)數(shù)據(jù)包就會建立連接，但由于客戶端此時并未響應(yīng)服務(wù)器端的請求，那此時服務(wù)器端就會一直在等待客戶端，這樣服務(wù)器端就白白浪費了一定的資源。若采用三次握手，服務(wù)器端沒有收到來自客戶端的再此確認(rèn)，則就會知道客戶端并沒有要求建立請求，就不會浪費服務(wù)器的資源。

四次揮手

正常報文: ACK ack seq

image
對于4次揮手，其實你仔細(xì)看是2次，因為TCP是全雙工的

為什么有TIME_WAIT（2MSL）狀態(tài)

MSL(Maximum Segment Lifetime)報文最長存活時間

  • 保證服務(wù)端正常關(guān)閉。因為有可能最后一個ACK丟失，所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。Server如果沒有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認(rèn)Server接收到了該ACK。Client會在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。
  • 2MSL可以保證本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段從網(wǎng)絡(luò)中消失。避免新舊連接混淆

MSL(Maximum Segment Lifetime)報文最大生存時間

Windows : MSL = 2 min

linux(Ubuntu, CentOs) : MSL = 60s

Unix : MSL = 30s

出現(xiàn)大量的Time_wait狀態(tài)的原因

https://coolshell.cn/articles/11564.html

TIME_WAIT 表示主動關(guān)閉，是服務(wù)器自己可控的

因為linux分配給一個用戶的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT兩種狀態(tài)如果一直被保持，那么意味著對應(yīng)數(shù)目的通道就一直被占著，一旦達(dá)到句柄數(shù)上限，新的請求就無法被處理了，接著就是大量Too Many Open Files異常，tomcat崩潰。。。

解決方法：

  • 修改最大文件句柄數(shù)
  • server端應(yīng)盡量減少主動關(guān)閉連接

出現(xiàn)大量的Close_wait狀態(tài)的原因

CLOSE_WAIT 表示被動關(guān)閉

原因：接收到客戶端的FIN，回復(fù)ACK。此時服務(wù)器進(jìn)入Close_wait，直到服務(wù)器發(fā)起關(guān)閉連接。

所以原因是服務(wù)器沒有及時關(guān)閉連接。即：對方關(guān)閉socket連接，我方忙于讀或者寫，沒有及時關(guān)閉連接

解決辦法：

  • 檢查代碼，特別是釋放資源的代碼
  • 檢查配置，特別是處理請求的線程配置

可靠傳輸

  • 序號
  • 確認(rèn)
  • 超時重傳

流量控制

基于滑動窗口。TCP使用滑動窗口做流量控制和亂序重排，匹配發(fā)送方的速率和接收方的速率

  • 發(fā)送方和接收方各有一個窗口
  • 接收方通過設(shè)置自己接收緩存的大小，動態(tài)的調(diào)整發(fā)送方的發(fā)送窗口大小，這就是接收窗口rwnd，即調(diào)整tcp報文段首部中的窗口字段值，來限制發(fā)送方向網(wǎng)絡(luò)注入報文的速率
  • 發(fā)送方根據(jù)當(dāng)前網(wǎng)絡(luò)擁塞程序的估計而確定窗口值，即cwnd (congenstion window)
  • 發(fā)送方的發(fā)送窗口取min(cwnd, rwnd)

擁塞控制

image

防止過多的數(shù)據(jù)注入網(wǎng)絡(luò)

針對的是cwnd（congestion window)，不是發(fā)送窗口

慢開始 & 擁塞避免

慢開始

  • cwnd指數(shù)增長至ssthresh，此時改用擁塞避免算法

擁塞避免

  • cwnd加法增大

當(dāng)網(wǎng)絡(luò)擁塞（沒有按時收到確認(rèn)，重傳計時器超時）

  • cwnd回1
  • ssthresh = cwnd / 2
  • 這樣做的目的是迅速減少網(wǎng)絡(luò)中的分組數(shù)

快重傳 & 快恢復(fù)

對慢開始 & 擁塞避免的改進(jìn)

  • 快重傳：當(dāng)發(fā)送方連續(xù)收到三個重復(fù)的ACK報文時，直接重傳對方尚未收到的報文段，不必等到計時器超時
  • 快恢復(fù)：在上面這種情況下，只是丟失個別報文段，而不是網(wǎng)絡(luò)擁塞。因此執(zhí)行快恢復(fù)
    • 令 ssthresh = cwnd = cwnd /2
    • 此時直接進(jìn)入擁塞避免：即cwnd加法增大
    • 由于跳過了cwnd從1開始，所以被稱為快恢復(fù)

流量控制和擁塞控制的區(qū)別：

  • 流量控制是為了匹配收發(fā)仿的速率，讓接收方能來得及接收
  • 擁塞控制是為了降低整個網(wǎng)絡(luò)的擁塞程度。

粘包

場景1：

客戶端和服務(wù)器建立一個連接，客戶端連續(xù)發(fā)送兩條消息，客戶端關(guān)閉與服務(wù)端的連接。

服務(wù)端一共就讀到一個數(shù)據(jù)包，這個數(shù)據(jù)包包含客戶端發(fā)出的兩條消息的完整信息，這個時候基于之前邏輯實現(xiàn)的服務(wù)端就蒙了，因為服務(wù)端不知道第一條消息從哪兒結(jié)束和第二條消息從哪兒開始，這種情況其實是發(fā)生了TCP粘包。

image

場景2：

服務(wù)端一共收到了兩個數(shù)據(jù)包，第一個數(shù)據(jù)包只包含了第一條消息的一部分，第一條消息的后半部分和第二條消息都在第二個數(shù)據(jù)包中，或者是第一個數(shù)據(jù)包包含了第一條消息的完整信息和第二條消息的一部分信息，第二個數(shù)據(jù)包包含了第二條消息的剩下部分，這種情況其實是發(fā)送了TCP拆，因為發(fā)生了一條消息被拆分在兩個包里面發(fā)送了，同樣上面的服務(wù)器邏輯對于這種情況是不好處理的。

image

發(fā)生TCP粘包、拆包主要是由于下面一些原因：

  1. 應(yīng)用程序?qū)懭氲臄?shù)據(jù)大于套接字緩沖區(qū)大小，這將會發(fā)生拆包。
  2. 應(yīng)用程序?qū)懭霐?shù)據(jù)小于套接字緩沖區(qū)大小，網(wǎng)卡將應(yīng)用多次寫入的數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)上，這將會發(fā)生粘包。
  3. 進(jìn)行mss（最大報文長度）大小的TCP分段，當(dāng)TCP報文長度-TCP頭部長度>mss的時候?qū)l(fā)生拆包。
  4. 接收方法不及時讀取套接字緩沖區(qū)數(shù)據(jù)，這將發(fā)生粘包。

粘包是由TCP協(xié)議本身造成的，TCP為提高傳輸效率，發(fā)送方往往要收集到足夠多的數(shù)據(jù)后才發(fā)送一個TCP段。若連續(xù)幾次需要send的數(shù)據(jù)都很少，通常TCP會根據(jù)negal優(yōu)化算法把這些數(shù)據(jù)合成一個TCP段后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)。

如何解決拆包粘包

既然知道了tcp是無界的數(shù)據(jù)流，且協(xié)議本身無法避免粘包，拆包的發(fā)生，那我們只能在應(yīng)用層數(shù)據(jù)協(xié)議上，加以控制。通常在制定傳輸數(shù)據(jù)時，可以使用如下方法：

  1. 使用帶消息頭的協(xié)議、消息頭存儲消息開始標(biāo)識及消息長度信息，服務(wù)端獲取消息頭的時候解析出消息長度，然后向后讀取該長度的內(nèi)容。
  2. 設(shè)置定長消息，服務(wù)端每次讀取既定長度的內(nèi)容作為一條完整消息。
  3. 設(shè)置消息邊界，服務(wù)端從網(wǎng)絡(luò)流中按消息編輯分離出消息內(nèi)容。

a)先基于第三種方法，假設(shè)區(qū)分?jǐn)?shù)據(jù)邊界的標(biāo)識為換行符"\n"（注意請求數(shù)據(jù)本身內(nèi)部不能包含換行符），數(shù)據(jù)格式為Json，例如下面是一個符合這個規(guī)則的請求包。

{"type":"message","content":"hello"}\n

注意上面的請求數(shù)據(jù)末尾有一個換行字符(在PHP中用雙引號字符串"\n"表示)，代表一個請求的結(jié)束。

b)基于第一種方法，可以制定，首部固定10個字節(jié)長度用來保存整個數(shù)據(jù)包長度，位數(shù)不夠補0的數(shù)據(jù)協(xié)議

0000000036{"type":"message","content":"hello"}

c)基于第一種方法，可以制定，首部4字節(jié)網(wǎng)絡(luò)字節(jié)序unsigned int，標(biāo)記整個包的長度

****{"type":"message","content":"hello all"}

其中首部四字節(jié)*號代表一個網(wǎng)絡(luò)字節(jié)序的unsigned int數(shù)據(jù)，為不可見字符，緊接著是Json的數(shù)據(jù)格式的包體數(shù)據(jù)。

SynFlood

在三次握手過程中，服務(wù)器發(fā)送SYN，ACK之后，收到客戶端的ACK之前的TCP連接稱為半連接(half-open connect)。此時服務(wù)器處于Syn_RECV狀態(tài)。當(dāng)收到ACK后，服務(wù)器轉(zhuǎn)入ESTABLISHED狀態(tài)。
　　Syn攻擊就是 攻擊客戶端 在短時間內(nèi)偽造大量不存在的IP地址，向服務(wù)器不斷地發(fā)送syn包，服務(wù)器回復(fù)確認(rèn)包，并等待客戶的確認(rèn)，由于源地址是不存在的，服務(wù)器需要不斷的重發(fā)直 至超時，這些偽造的SYN包將長時間占用未連接隊列，正常的SYN請求被丟棄，目標(biāo)系統(tǒng)運行緩慢，嚴(yán)重者引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓。

目前，Linux下默認(rèn)會進(jìn)行5次重發(fā)SYN-ACK包，重試的間隔時間從1s開始，下次的重試間隔時間是前一次的雙倍，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s, 總共31s, 稱為指數(shù)退避，第5次發(fā)出后還要等32s才知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s, TCP才會把斷開這個連接。由于，SYN超時需要63秒，那么就給攻擊者一個攻擊服務(wù)器的機(jī)會，攻擊者在短時間內(nèi)發(fā)送大量的SYN包給Server(俗稱SYN flood攻擊)，用于耗盡Server的SYN隊列。

檢測SYN攻擊非常的方便，當(dāng)你在服務(wù)器上看到大量的半連接狀態(tài)時，特別是源IP地址是隨機(jī)的，基本上可以斷定這是一次SYN攻擊。在LINUX下可以如下命令檢測是否被Syn攻擊：

`[root@rsync_test ~]``# netstat -n | awk '/^tcp/ {++sam[$NF]} END {for(num in sam)print num,sam[num]}'``TIME_WAIT 30``FIN_WAIT1 1``ESTABLISHED 615``SYN_RECV 2`

防護(hù)措施

  • 縮短SYN Timeout時間
  • Syn Cache
    服務(wù)端在收到SYN報文時，在一個專用HASH表cache中保存這種半連接信息，直到收到正確的回應(yīng)ACK報文再分配TCB。這個開銷遠(yuǎn)小于TCB的開銷。還需要保存序列號。
  • Syn Cookie
    1. 使用對方的IP、端口、己方IP、端口的固定信息，生成 Sequence Number
    2. SYN 隊列滿后，通過 tcp_syncookies 參數(shù)回發(fā) SYN cookie
      1. tcp_syncookies是一個開關(guān)，是否打開SYN Cookie功能，該功能可以防止部分SYN攻擊。
    3. 若為正常連接則 client 會回發(fā) SYN cookie，直接建立連接分配 TCB 。
    4. 攻擊者不會回復(fù)所以，正常的回復(fù)了SYN cookie 就可以在隊列外直接建立
  • 它的基本原理非常簡單，那就是“完成三次握手前不為任何一個連接分配任何資源”

SYN Cookie是對TCP服務(wù)器端的三次握手做一些修改，專門用來防范SYN Flood攻擊的一種手段。它的原理是，在TCP服務(wù)器接收到TCP SYN包并返回TCP SYN + ACK包時，不分配一個專門的數(shù)據(jù)區(qū)，而是根據(jù)這個SYN包計算出一個cookie值。這個cookie作為將要返回的SYN ACK包的初始序列號。當(dāng)客戶端返回一個ACK包時，根據(jù)包頭信息計算cookie，與返回的確認(rèn)序列號(初始序列號 + 1)進(jìn)行對比，如果相同，則是一個正常連接，然后，分配資源，建立連接。

SYNC COOKIES 就是這個序列號的一
個特殊實現(xiàn)

* 初始 5 位： t mod 32，t 是時間戳
* 接下 3 位： mss 的編碼值
* 最后 24 位： 服務(wù)器 Port/ip，客戶端 Port/ip 值的 hash

客戶端收到這個序列號 n 之后，發(fā)送 n + 1 給服務(wù)器，服務(wù)器通過 n 來比對 sync
cookie

在開啟了 sync cookie 的情況下，sync queue 滿了的時候，連接再也不被丟掉，而是直
接返回相應(yīng)的 SYN/ACK 報文，看起來就像 sync queue 增大了一樣。

連接隊列

服務(wù)器端也會維護(hù)兩種隊列，處于SYN_RCVD狀態(tài)的半連接隊列，而處于ESTABLISHED狀態(tài)但仍未被應(yīng)用程序accept的為全連接隊列。如果這兩個隊列滿了之后，就會出現(xiàn)各種丟包的情形。

3 TCP與UDP

  • TCP面向連接；UDP是無連接的
  • TCP提供可靠的服務(wù)。UDP盡最大努力交付
  • TCP面向字節(jié)流；UDP是面向報文的
  • TCP有擁塞控制。UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低
  • 每一條TCP連接只能是點到點的；UDP支持一對一，一對多，多對一和多對多的交互通信

4 IP

尋址

A -> B

  • A將自己的ip和子網(wǎng)掩碼與運算得到網(wǎng)段，將B的ip與子網(wǎng)掩碼與運算得到子網(wǎng)段，對比。

  • 如果是同一網(wǎng)段，直接發(fā)到B

    • ARP廣播，找到B的mac地址

  • 如果是不同網(wǎng)段

    • 查找路由表如何到達(dá)目的網(wǎng)段，目的IP與各網(wǎng)絡(luò)的掩碼與運算
      • 直接交付
      • 間接交付
      • 默認(rèn)路由

IP數(shù)據(jù)包分片

image

各層數(shù)據(jù)包長度：

HTTP: 無

TCP: 無，依靠IP層分片

UDP: 65535

IP: 65535，有分組長度字段

以太網(wǎng)：1500

以太網(wǎng)就是一種基于總線的、廣播式的局域網(wǎng)絡(luò)，CSMA/CD協(xié)議

廣域網(wǎng)：576

分片重組是由ip負(fù)責(zé)，流量控制和有序傳輸由tcp控制

5HTTP

HTTP1.1

特點：connection: keepalive 長連接

存在效率問題

  • 第一個：串行的文件傳輸
  • 第二個：連接數(shù)過多

HTTP2

  • 多路復(fù)用
    • 允許同時通過單一的 HTTP/2 連接發(fā)起多重的請求-響應(yīng)消息
  • 二進(jìn)制分幀
    • 幀對數(shù)據(jù)進(jìn)行順序
    • 傳輸?shù)拿總€幀都關(guān)聯(lián)到一個“流”

在HTTP1.1的協(xié)議中，我們傳輸?shù)?code>request和response都是基本于文本的，這樣就會引發(fā)一個問題：所有的數(shù)據(jù)必須按順序傳輸，比如需要傳輸：hello world，只能從h到d一個一個的傳輸，不能并行傳輸，因為接收端并不知道這些字符的順序，所以并行傳輸在HTTP1.1是不能實現(xiàn)的。

image

HTTP/2引入二進(jìn)制數(shù)據(jù)幀和流的概念，其中幀對數(shù)據(jù)進(jìn)行順序標(biāo)識，如下圖所示，這樣瀏覽器收到數(shù)據(jù)之后，就可以按照序列對數(shù)據(jù)進(jìn)行合并，而不會出現(xiàn)合并后數(shù)據(jù)錯亂的情況。同樣是因為有了序列，服務(wù)器就可以并行的傳輸數(shù)據(jù)，這就是流所做的事情。

image

HTTPS

image

HTTPS數(shù)據(jù)傳輸流程

  • 服務(wù)端配置：采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書。這套證書其實就是一對公鑰和私鑰。
  • 客戶端發(fā)起HTTPS請求：就是用戶在瀏覽器中輸入一個https網(wǎng)址，連接到server的443端口。
  • 服務(wù)端傳送證書：即公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時間等。
  • 客戶端解析證書：由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時間等。如果證書沒有問題，
  • 傳送隨機(jī)值（私鑰）：客戶端生成一個隨機(jī)值，然后用證書對該隨機(jī)值進(jìn)行加密并發(fā)送給服務(wù)端。
  • 服務(wù)端解密隨機(jī)值（私鑰）：服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機(jī)值。
  • 服務(wù)端傳輸加密后的信息：服務(wù)端將要傳送的信息用隨機(jī)值（私鑰）加密后，傳送給客戶端。
  • 客戶端解密信息：客戶端使用隨機(jī)值（私鑰）解密服務(wù)端發(fā)送的加密信息，獲取解密后的信息。

區(qū)別

  • HTTPS需要到CA（電子認(rèn)證服務(wù)）申請證書，HTTP不需要
  • HTTPS密文傳輸，HTTP明文傳輸
  • 連接方式不同，HTTPS默認(rèn)使用443端口，HTTP使用80端口

6.Socket

Socket并不是一個協(xié)議，是位于應(yīng)用層和傳輸層中間的一個抽象層

Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。在設(shè)計模式中，Socket其實就是一個門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。

以下假設(shè)使用tcp

如果面向tcp編程的話，tcp的三次握手，四次揮手，流量控制，可靠傳輸，擁塞控制等等都太復(fù)雜了。而我們其實并不需要自己去做。就有一個封裝好的東西幫我們?nèi)プ觯蔷褪莝ocket。

image

客戶端：

clientfd = socket(...);
connect(clientfd, server_ip, server_port); // 三次握手

send();
receive();

close(clientfd) // 四次揮手

服務(wù)端：

listenfd = socket();
bind(listenfd, server_port);
listen(listenfd);
while(true){
  connfd = accept(listenfd,...); // 三次握手
  receive();
  send();
}

8 從輸入URL到頁面加載發(fā)生了什么

  1. 應(yīng)用層--發(fā)起請求邏輯HTTP
  2. 傳輸層--TCP
  3. 網(wǎng)絡(luò)層--包路由（IP）
  4. 數(shù)據(jù)鏈路層--幀（似乎是包的容器）
  5. 物理層--bit流（bitstreams）

假設(shè)是HTTP

瀏覽器會改變scheme為https，使用默認(rèn)的443端口重新發(fā)送請求

地址解析

從url中分解出協(xié)議名、主機(jī)名、 端口、對象路徑等

如果是不填寫協(xié)議名稱，則自動添加http:// .:80 Get方法

如果是https，使用默認(rèn)的443端口發(fā)送請求，進(jìn)入https過程

DNS解析

采用UDP傳輸

  1. 瀏覽器緩存
  2. 本地的hosts文件
  3. 本地域名服務(wù)器
    1. 根域名服務(wù)器
    2. 頂級域名服務(wù)器
    3. 權(quán)限域名服務(wù)器
    4. 本地DNS服務(wù)器就把請求發(fā)至13臺根DNS ( . )，根DNS服務(wù)器收到請求后會判斷這個域名(.com)是誰來授權(quán)管理，并會返回一個負(fù)責(zé)該頂級域名服務(wù)器的一個IP。
    5. 聯(lián)系負(fù)責(zé).com域的這臺服務(wù)器（頂級域名服務(wù)器）。
      1. 返回baidu.com給本地DNS服務(wù)器。
    6. 本地域名服務(wù)器向權(quán)限域名服務(wù)器查找www.baidu.com的地址（權(quán)限域名服務(wù)器）。

封裝 HTTP 請求數(shù)據(jù)包

封裝 TCP 包并建立連接

三次握手

封裝成 TCP 包，瀏覽器會選擇一個大于1024的本機(jī)端口向目標(biāo)IP地址的80端口發(fā)起TCP連接請求，建立 TCP 連接(TCP 的三次握手)

將報文段的數(shù)據(jù)分割成以報文段為單位的數(shù)據(jù)包進(jìn)行管理，并為它們編號 <序號，確認(rèn)號>

流量控制 & 擁塞控制

網(wǎng)絡(luò)層

尋找路由

ip層數(shù)據(jù)包分片<1500, 576>

數(shù)據(jù)鏈路層

ARP協(xié)議

  • 查表
  • 廣播

物理層比特流傳輸

斷開TCP連接

四次揮手

9 ARP

  • 把32bit的IP地址變換成48bit的以太網(wǎng)地址
  • ARP發(fā)送一份稱為ARP請求的以太網(wǎng)數(shù)據(jù)幀給以太網(wǎng)上的每個主機(jī)。這個過程稱為廣播。ARP請求數(shù)據(jù)幀中包含目的主機(jī)的IP地址，其意思是“如果你是這個IP地址的擁有者，請回答你的硬件地址。”
  • 目的主機(jī)的ARP層收到這個廣播報文后，識別出這是發(fā)送端在尋問它的IP地址，于是發(fā)送一個ARP應(yīng)答。這個ARP應(yīng)答包含IP地址及對應(yīng)的硬件地址；
  • ARP高速緩存在它的運行過程中非常關(guān)鍵，我們可以用arp命令對高速緩存進(jìn)行檢查和操作
arp -a # 查看本機(jī)arp

11 Rip & OSPF

常見的路由選擇協(xié)議有：RIP協(xié)議、OSPF協(xié)議。

  • RIP協(xié)議（路由信息協(xié)議）：
    • 基于距離向量的路由選擇協(xié)議
    • 路由的度量標(biāo)準(zhǔn)是跳數(shù)，最大跳數(shù)是15跳，如果大于15跳，它就會丟棄數(shù)據(jù)包
    • 僅和相鄰路由器交換當(dāng)前路由器所知道的全部信息
    • 應(yīng)用層協(xié)議,使用UDP傳輸數(shù)據(jù),端口520
  • OSPF協(xié)議（開放最短路由優(yōu)先）：
    • 鏈路狀態(tài)路由選擇協(xié)議，底層是迪杰斯特拉(Dijkstra)算法
    • 路由的度量標(biāo)準(zhǔn)是帶寬，延遲
    • 向本自治系統(tǒng)中所有路由器發(fā)送與本路由器相鄰的所有路由器的鏈路狀態(tài)，但這只是路由器知道的部分信息。
    • 網(wǎng)絡(luò)層協(xié)議,直接IP數(shù)據(jù)報傳輸． 端口89。

12 csma/cd ppp

ppp協(xié)議是點到點的數(shù)據(jù)鏈路層協(xié)議，采用點對點傳輸網(wǎng)絡(luò)拓?fù)錁?gòu)型主要有4種：星形、樹型、環(huán)型和網(wǎng)狀型。ppp協(xié)議主要是在廣域網(wǎng)鏈路層中使用。
csma/cd是廣播信道的數(shù)據(jù)鏈路層協(xié)議，它是早期共享型以太網(wǎng)所使用的一種傳輸協(xié)議，而以太網(wǎng)是局域網(wǎng)組網(wǎng)的一種協(xié)議，所以csma/cd只是用于局域網(wǎng)范圍內(nèi)，并且一般采用的傳輸網(wǎng)絡(luò)拓?fù)錁?gòu)型是總線型。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容