點擊上方藍色字體，選擇“標星公眾號”
優(yōu)質(zhì)文章，第一時間送達
計算機網(wǎng)絡(luò)模型：
TCP/IP 與 OSI 都是為了使網(wǎng)絡(luò)中的兩臺計算機能夠互相連接并實現(xiàn)通信與回應，但他們最大的不同在于，OSI 是一個理論上的網(wǎng)絡(luò)通信模型，而 TCP/IP 則是實際上的網(wǎng)絡(luò)通信標準。
一、OSI七層模型：
1、物理層：實現(xiàn)計算機節(jié)點之間比特流的透明傳輸，規(guī)定傳輸媒體接口的標準，屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異，使數(shù)據(jù)鏈路層不必關(guān)心網(wǎng)絡(luò)的具體傳輸介質(zhì)，按照物理層規(guī)定的標準傳輸數(shù)據(jù)就行
2、數(shù)據(jù)鏈路層：通過差錯控制、流量控制等方法，使有差錯的物理線路變?yōu)闊o差錯的數(shù)據(jù)鏈路。
數(shù)據(jù)鏈路層的幾個基本方法：數(shù)據(jù)封裝成楨、透明傳輸、差錯控制、流量控制。
封裝成楨：把網(wǎng)絡(luò)層數(shù)據(jù)報加頭和尾，封裝成幀，幀頭中包括源MAC地址和目的MAC地址。
透明傳輸：零比特填充、轉(zhuǎn)義字符。
差錯控制：接收者檢測錯誤,如果發(fā)現(xiàn)差錯，丟棄該幀，差錯控制方法有 CRC 循環(huán)冗余碼
流量控制：控制發(fā)送的傳輸速度，使得接收方來得及接收。傳輸層TCP也有流量控制功能，但TCP是端到端的流量控制，鏈路層是點到點（比如一個路由器到下一個路由器）
3、網(wǎng)絡(luò)層：實現(xiàn)網(wǎng)絡(luò)地址與物理地址的轉(zhuǎn)換，并通過路由選擇算法為分組通過通信子網(wǎng)選擇最適當?shù)穆窂?/span>
網(wǎng)絡(luò)層最重要的一個功能就是：路由選擇。路由一般包括路由表和路由算法兩個方面。每個路由器都必須建立和維護自身的路由表，一種是靜態(tài)維護，也就是人工設(shè)置，適用于小型網(wǎng)絡(luò)；另一種就是動態(tài)維護，是在運行過程中根據(jù)網(wǎng)絡(luò)情況自動地動態(tài)維護路由表。
4、傳輸層：提供源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸，傳輸層協(xié)議為不同主機上運行的進程提供邏輯通信。
5、會話層：是用戶應用程序和網(wǎng)絡(luò)之間的接口，負責在網(wǎng)絡(luò)中的兩節(jié)點之間建立、維持、終止通信。
6、表示層：處理用戶數(shù)據(jù)的表示問題，如數(shù)據(jù)的編碼、格式轉(zhuǎn)換、加密和解密、壓縮和解壓縮。
7、應用層：為用戶的應用進程提供網(wǎng)絡(luò)通信服務(wù)，完成和實現(xiàn)用戶請求的各種服務(wù)。
二、TCP/IP模型
TCP/IP協(xié)議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構(gòu)成互聯(lián)網(wǎng)基礎(chǔ)的網(wǎng)絡(luò)協(xié)議，是Internet的核心協(xié)議。TCP/IP協(xié)議族按照層次由上到下，層層包裝。
上圖表示了TCP/IP協(xié)議中每個層的作用，而TCP/IP協(xié)議通信的過程其實就對應著數(shù)據(jù)入棧與出棧的過程。入棧的過程，數(shù)據(jù)發(fā)送方每層不斷地封裝首部與尾部，添加一些傳輸?shù)男畔?，確保能傳輸?shù)侥康牡亍３鰲５倪^程，數(shù)據(jù)接收方每層不斷地拆除首部與尾部，得到最終傳輸?shù)臄?shù)據(jù)。
網(wǎng)絡(luò)層：
實現(xiàn)網(wǎng)絡(luò)地址與物理地址的轉(zhuǎn)換，并通過路由選擇算法為分組通過通信子網(wǎng)選擇最適當?shù)穆窂?/span>
1、IP地址與物理地址：
物理地址是數(shù)據(jù)鏈路層和物理層使用的地址，IP地址是網(wǎng)絡(luò)層和以上各層使用的地址，是一種邏輯地址，其中ARP協(xié)議將IP地址轉(zhuǎn)換成物理地址。
2、ARP地址解析協(xié)議的工作原理：
ARP 是根據(jù) IP 地址獲取 MAC 地址的一種協(xié)議，核心原理就是廣播發(fā)送ARP請求，單播發(fā)送ARP響應
（1）每個主機都在自己的ARP緩沖區(qū)中建立一個ARP列表，以表示 IP 地址和 MAC 地址之間的對應關(guān)系。
（2）當源主機要發(fā)送數(shù)據(jù)時，先檢查ARP列表中是否有該 IP 地址對應的 MAC 地址，如果有，則直接發(fā)送數(shù)據(jù)；如果沒有，就向本網(wǎng)段的所有主機發(fā)送ARP數(shù)據(jù)包，用于查詢目的主機的MAC地址，該數(shù)據(jù)包包括的內(nèi)容有：源主機IP地址，源主機MAC地址，目的主機的IP。
（3）當本網(wǎng)絡(luò)的所有主機收到該ARP數(shù)據(jù)包時，首先檢查數(shù)據(jù)包中的IP地址是否是自己的IP地址，如果不是，則忽略該數(shù)據(jù)包，如果是，則首先從數(shù)據(jù)包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經(jīng)存在，則覆蓋，然后將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址。
（4）源主機收到 ARP 響應包后，將目的主機的 IP 和 MAC 地址寫入ARP列表，并利用此信息發(fā)送數(shù)據(jù)。如果源主機一直沒有收到ARP響應數(shù)據(jù)包，表示ARP查詢失敗
3、RARP逆地址解析協(xié)議：
RARP是逆地址解析協(xié)議，作用是完成硬件地址到IP地址的映射，主要用于無盤工作站，因為給無盤工作站配置的IP地址不能保存。工作流程：在網(wǎng)絡(luò)中配置一臺RARP服務(wù)器，里面保存著 MAC 地址和 IP 地址的映射關(guān)系，當無盤工作站啟動后，就封裝一個RARP數(shù)據(jù)包，里面有其MAC地址，然后廣播到網(wǎng)絡(luò)上去，當服務(wù)器收到請求包后，就查找對應的MAC地址的IP地址裝入響應報文中發(fā)回給請求者。因為需要廣播請求報文，因此RARP只能用于具有廣播能力的網(wǎng)絡(luò)。
4、DHCP協(xié)議：
動態(tài)主機配置協(xié)議，對 IP地址進行集中管理和分配，提升地址的使用率，通過DHCP協(xié)議，可以使客戶機自動獲得服務(wù)器分配的lP地址和子網(wǎng)掩碼
5、ICMP協(xié)議：
因特網(wǎng)控制報文協(xié)議，用于在IP主機、路由器之間傳遞控制消息（控制消息是指網(wǎng)絡(luò)通不通、主機是否可達、路由器是否可用等網(wǎng)絡(luò)本身的消息），確認 IP 包是否成功到達目標地址。因為 IP 協(xié)議并不是一個可靠的協(xié)議，它不保證數(shù)據(jù)被送達，當傳送IP數(shù)據(jù)包發(fā)生錯誤，比如主機不可達、路由不可達等等，ICMP協(xié)議將會把錯誤信息封包，然后傳送回給主機，給主機一個處理錯誤的機會。
ICMP報文有兩種：差錯報告報文和詢問報文。以下是4種常見的ICMP差錯報告報文
6、交換機與路由器的區(qū)別：
（1）工作所處的OSI層次不一樣，交換機工作在OSI第二層數(shù)據(jù)鏈路層，路由器工作在OSI第三層網(wǎng)絡(luò)層；
（2）尋址方式不同：交換機根據(jù)MAC地址尋址，路由器根據(jù)IP地址尋址；
（3）轉(zhuǎn)發(fā)速不同：交換機的轉(zhuǎn)發(fā)速度快，路由器轉(zhuǎn)發(fā)速度相對較慢。
7、路由選擇協(xié)議：
（1）內(nèi)部網(wǎng)關(guān)協(xié)議IGP：
① RIP(Routing Information Protocol）：是一種動態(tài)路由選擇協(xié)議，基于距離矢量算法，使用“跳數(shù)”來衡量到達目標地址的路由距離，并且只與自己相鄰的路由器交換信息，范圍限制在15跳之內(nèi)。
② OSPF：開放最短路徑優(yōu)先協(xié)議，使用Dijskra算法計算出到達每一網(wǎng)絡(luò)的最短路徑，并在檢測到 鏈路的情況發(fā)生變化時（如鏈路失效），就執(zhí)行該算法快速收斂到新的無環(huán)路拓撲。
（2）外部網(wǎng)關(guān)協(xié)議：
BGP：邊界網(wǎng)關(guān)協(xié)議，BGP 是力求尋找一條能夠到達目的網(wǎng)絡(luò) 且 較好的路由，而并非要尋找一條最佳路由。BGP采用路徑向量路由選擇協(xié)議。
傳輸層：
傳輸層主要提供不同主機上進程間 邏輯通信 + 可靠傳輸 或者 不可靠傳輸?shù)墓δ堋?/span>
一、TCP 和 UDP：
1、傳輸控制協(xié)議TCP 和 用戶數(shù)據(jù)報協(xié)議UDP的區(qū)別？
（1）TCP是面向字節(jié)流的，基本傳輸單位是TCP報文段；UDP是面向報文的，基本傳輸單位是是用戶數(shù)據(jù)報；
（2）TCP 注重安全可靠性，連接雙方在進行通信前，需進行三次握手建立連接。UDP 是無連接的，使用最大努力交付，即不保證可靠交付。
（3）UDP 不需要連接等待，所以數(shù)據(jù)傳輸快，而 TCP 傳輸效率相對較低
（4）TCP首部開銷是20個字節(jié)；UDP的首部開銷是8個字節(jié)，這也是減少網(wǎng)絡(luò)傳輸開銷的一方面
（5）TCP有擁塞控制和流量控制，而UDP沒有擁塞控制和流量控制
（6）TCP支持點對點通信，提供全雙工通信，不提供廣播或多播服務(wù)；UDP支持一對一、一對多、多對一、多對多的通信模式。
2、TCP 和 UDP 的適用場景：
（1）當對網(wǎng)絡(luò)通訊質(zhì)量要求不高時，并且要求網(wǎng)絡(luò)通訊速度能盡量的快，這時就可以使用UDP。比如即使通信：語音、 視頻 、直播等
（2）當對網(wǎng)絡(luò)通訊質(zhì)量有要求時，要求整個數(shù)據(jù)準確無誤可靠的傳遞給對方，這時就適用使用 TCP 協(xié)議，一般用于文件傳輸、發(fā)送和接收郵件等場景。比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸?shù)膮f(xié)議都是使用 TCP 協(xié)議
① TCP對應的協(xié)議：
FTP：文件傳輸協(xié)議，使用21端口
Telnet：遠程終端接入，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基于DOS模式下的通信服務(wù)。
SMTP：郵件傳送協(xié)議，用于發(fā)送郵件，使用25端口
POP3：郵件傳送協(xié)議，P用于接收郵件。使用110端口
HTTP：萬維網(wǎng)超文本傳輸協(xié)議，是從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議
② UDP對應的協(xié)議：
DNS：域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址，使用53號端口；
SNMP：網(wǎng)絡(luò)管理協(xié)議，用來管理網(wǎng)絡(luò)設(shè)備，使用161號端口；
TFTP：簡單文件傳輸協(xié)議，提供不復雜、開銷不大的文件傳輸服務(wù)，使用 69 端口；
NFS：遠程文件服務(wù)器
RIP：路由信息協(xié)議
DHCP：動態(tài)主機配置協(xié)議
IGMP：網(wǎng)際組管理協(xié)議
3、TCP的首部字段：
（1）源端口和目的端口：分別占16位，指發(fā)送方應用程序的端口和目的方應用程序的端口號，通過 IP 地址 + 端口號就可以確定一個進程地址
（2）序號（Sequense Number，SN）：在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號，該字段表示本報文段所發(fā)送數(shù)據(jù)的第一個字節(jié)的序號。（初始序號稱為 Init Sequense Number, ISN）
例如，一報文段的序號是 101，共有 100 字節(jié)的數(shù)據(jù)。這就表明：本報文段的數(shù)據(jù)的第一個字節(jié)的序號是 101，最后一個字節(jié)的序號是 200。顯然，下一個報文段的數(shù)據(jù)序號應當從 201 開始，即下一個報文段的序號字段值應為 201。
（3）確認號 ack：期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。若確認號為 N，則表明：到序號 N-1 為止的所有數(shù)據(jù)都已正確收到。
（4）頭部長度：指出 TCP報文段的數(shù)據(jù)起始處 距離 TCP報文段的起始處有多遠。這個字段實際上是指出TCP報文段的首部長度。
（5）保留位：占6位，應置為 0，保留為今后使用。
（6）6個控制位：用于說明該報文段的性質(zhì)：
① 緊急位URG：當 URG = 1 時，表明此報文段中有緊急數(shù)據(jù)，是高優(yōu)先級的數(shù)據(jù)，應盡快發(fā)送，不用在緩存中排隊。
② 確認ACK：僅當 ACK = 1 時確認號字段才有效，當 ACK = 0 時確認號無效。TCP 規(guī)定，在連接建立后所有傳送的報文段都必須把 ACK 置為 1。
③ 推送PSH：接收方收到 PSH = 1 的報文段時，就直接發(fā)送給應用進程，而不用等到整個緩沖區(qū)都填滿了后再向上傳送。
④ 復位RST：當 RST = 1 時，表明 TCP 連接中出現(xiàn)了嚴重錯誤（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接。
⑤ 同步SYN：SYN = 1 表示這是一個連接請求或連接接受報文。當 SYN = 1 而 ACK = 0 時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使 SYN = 1 且 ACK = 1。
⑥ 終止FIN：用來釋放一個連接。當 FIN = 1時，表明此報文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。
（7）窗口大?。?6位，用于控制發(fā)送端的滑動窗口大小
（8）校檢和：16位，校驗數(shù)據(jù)段是否未被修改
（9）緊急指針：16位。
二、TCP連接的建立與斷開：
1、建立連接的三次握手：
（1）第一次握手：客戶端向服務(wù)端發(fā)送一個 SYN 報文（SYN = 1），并指明客戶端初始化序列號 ISN，即seq = x，表示本報文所發(fā)送的第一個字節(jié)的序號。此時客戶端處于 SYN_Sent 狀態(tài)，等待服務(wù)端確認。
三次握手的一個重要功能是客戶端和服務(wù)端交換 ISN，以便讓對方知道接下來接收數(shù)據(jù)時如何按序列號組裝數(shù)據(jù)。
ISN 是動態(tài)生成的，并非固定，因此每個連接都將具有不同的 ISN。如果 ISN 是固定的，攻擊者很容易猜出后續(xù)的確認號。
（2）第二次握手：服務(wù)端收到數(shù)據(jù)包后，由 SYN = 1 知道客戶端請求建立連接，那么就會對這個TCP 連接分配緩存和變量（緩存指的是一個字節(jié)流隊列），接著返回一個確認報文：設(shè)置 SYN = 1，ACK = 1，同時指定自己的初始化序列號 ISN，即圖中的 seq = y，并把客戶端的 ISN + 1 作為確認號 ack 的值，表示已經(jīng)收到了客戶端發(fā)來的的 SYN 報文，希望收到的下一個數(shù)據(jù)的第一個字節(jié)的序號是 x + 1，此時服務(wù)端進入SYN_REVD狀態(tài)。
（3）第三次握手：客戶端收到確認后，檢查ACK是否為1，ack是否為 x +1，如果正確，則給服務(wù)端發(fā)送一個 ACK 報文：設(shè)置 ACK = 1，把服務(wù)端的 ISN + 1 作為 ack 的值，表示已經(jīng)收到了服務(wù)端發(fā)來的 SYN 報文，希望收到的下一個數(shù)據(jù)的第一個字節(jié)的序號是 y + 1，并指明此時客戶端的序列號 seq = x + 1，此時客戶端和服務(wù)器端都進入 ESTABLISHED 狀態(tài)。完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。
此時 SYN 控制位變?yōu)?0，表示這不是建立連接的請求了，要正式發(fā)數(shù)據(jù)了。
2、為什么不能用兩次握手進行建立連接？
（1）三次握手目的是確認雙方的接收與發(fā)送能力是否正常，同步連接雙方的初始化序列號 ISN，為后面的可靠性傳輸做準備。而兩次握手只有服務(wù)端對客戶端的起始序列號做了確認，但客戶端卻沒有對服務(wù)端的初始序列號做確認，不能保證傳輸?shù)目煽啃浴?/span>
（2）三次握手可以防止已失效的連接請求報文段突然又傳送到了服務(wù)端，導致服務(wù)器錯誤地建立連接，浪費服務(wù)端的連接資源。
客戶端發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達Server。本來這是一個早已失效的報文段，但Server收到此失效的連接請求報文段后：
① 假設(shè)不采用“三次握手”，那么只要Sever發(fā)出確認，新的連接就建立了。但由于現(xiàn)在Client并沒有發(fā)出建立連接的請求，因此不會理睬Server的確認，也不會向Server發(fā)送數(shù)據(jù)。而Server卻以為新的連接已經(jīng)建立，并一直等待Client發(fā)來數(shù)據(jù)，這樣，Server的很多資源就白白浪費掉了
② 而采用“三次握手”協(xié)議，只要Server收不到來自Client的確認，就知道Client并沒有要求建立請求，就不會建立連接了。
3、斷開連接的四次揮手：
（1）第一次揮手：客戶端發(fā)送一個 FIN 報文，設(shè)置 FIN = 1 并指定序列號 seq = u（u 是之前傳送過來的最后一個字節(jié)的序號 + 1），主動關(guān)閉 TCP 連接，此時客戶端進入FIN_WAIT_1狀態(tài)；
（2）第二次揮手：服務(wù)端收到 FIN 報文后，由FIN=1 知道客戶端請求關(guān)閉連接，則返回確認報文：設(shè)置ACK = 1，ack = u + 1，seq = v（v 的值取決于服務(wù)器發(fā)送給客戶端之前的一個包確認號是多少）
（3）第三次揮手：當服務(wù)端沒有要向客戶端發(fā)送的數(shù)據(jù)時，就向客戶端發(fā)送一個 FIN 報文，設(shè)置 FIN = 1 并指定序列號 seq = w（w 的值取決于服務(wù)器發(fā)送給客戶端之前的一個包確認號是多少），用于關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送。此時服務(wù)器處于 LAST_ACK 狀態(tài)
（4）第四次揮手：客戶端收到 FIN 報文后，發(fā)送給服務(wù)端一個 ACK 報文作為應答：設(shè)置 ACK=1 和 ack = w +1。發(fā)送之后，客戶端處于 TIME_WAIT狀態(tài)，如果服務(wù)端接收到這個數(shù)據(jù)包，則進入CLOSED狀態(tài)，完成四次揮手。
4、為什么需要 TIME_WAIT 狀態(tài)：
TIME_WAIT 狀態(tài)持續(xù) 2MSL（最大報文存活時間），約4分鐘才轉(zhuǎn)換成CLOSE狀態(tài)。由于TIME_WAIT 的時間會非常長，因此服務(wù)端應盡量減少主動關(guān)閉連接，TIME_WAIT 的主要作用有：
（1）重發(fā)丟失的 ACK 報文，保證連接可靠的關(guān)閉：
由于網(wǎng)絡(luò)等原因，無法保證最后一次揮手的 ACK 報文一定能傳送給對方，如果 ACK 丟失，對方會超時重傳 FIN，主動關(guān)閉端會再次響應ACK過去；如果沒有 TIME_WAIT 狀態(tài)，直接關(guān)閉，對方重傳的FIN報文則被響應一個RST報文，此RST會被動關(guān)閉端被解析成錯誤。同時，服務(wù)器就因為接收不到客戶端的信息而無法正常關(guān)閉。
（2）保證本次連接的重復數(shù)據(jù)段從網(wǎng)絡(luò)中消失：
如果存在兩個連接，第一個連接正常關(guān)閉，第二個相同的連接緊接著建立；如果第一個連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接之后才到達，則會干擾第二連接，等待 2MSL 可以讓上次連接的報文數(shù)據(jù)消逝在網(wǎng)絡(luò)中。
5、為什么需要四次揮手：
TCP 是全雙工模式，并且支持半關(guān)閉特性，提供了連接的一端在結(jié)束發(fā)送后還能接收來自另一端數(shù)據(jù)的能力。任何一方都可以在數(shù)據(jù)傳送結(jié)束后發(fā)出連接釋放的通知，待對方確認后進入半關(guān)閉狀態(tài)。當另一方也沒有數(shù)據(jù)再發(fā)送的時候，則發(fā)出連接釋放通知，對方確認后就完全關(guān)閉了 TCP 連接。
通俗的來說，兩次握手就可以釋放一端到另一端的 TCP 連接，完全釋放連接一共需要四次握手。
6、什么是SYN洪泛：
SYN 洪泛是指利用 TCP 需要三次握手的特性，攻擊者偽造 SYN 報文向服務(wù)器發(fā)起連接，服務(wù)器在收到報文后用 ACK 應答，但之后攻擊者不再對該響應進行應答，造成一個半連接。假設(shè)攻擊者發(fā)送大量這樣的報文，那么被攻擊主機就會造成大量的半連接，耗盡其資源，導致正常的 SYN 請求因為隊列滿而被丟棄，使得正常用戶無法訪問。
半連接隊列：服務(wù)器第一次收到客戶端的 SYN 之后，就會處于 SYN_RCVD 狀態(tài)，此時雙方還沒有完全建立其連接，服務(wù)器會把這種狀態(tài)下的請求連接放在一個隊列里，我們把這種隊列稱之為半連接隊列。當然還有一個全連接隊列，完成三次握手后建立起的連接就會放在全連接隊列中。
7、三次握手過程中是否可以攜帶數(shù)據(jù)：
第三次握手時是可以攜帶數(shù)據(jù)的，但第一二次握手時不可以攜帶數(shù)據(jù)。
（1）假如第一次握手可以攜帶數(shù)據(jù)的話，那么會放大 SYN 洪泛。如果有人要惡意攻擊服務(wù)器，每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù)，然后瘋狂重復發(fā)送 SYN 報文的話，就會讓服務(wù)器開辟大量的緩存來接收這些報文，內(nèi)存會很容易耗盡，從而拒絕服務(wù)。
（2） 第三次握手時客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)，對于客戶端來說，他已經(jīng)建立起連接了，并且已經(jīng)知道服務(wù)器的接收和發(fā)送能力是正常的，所以也就可以攜帶數(shù)據(jù)了。
8、TCP的粘包和拆包：
程序需要發(fā)送的數(shù)據(jù)大小和TCP報文段能發(fā)送MSS（Maximum Segment Size，最大報文長度）是不一樣的。大于MSS時，就需要把程序數(shù)據(jù)拆分為多個TCP報文段，稱之為拆包；小于時，則要考慮合并多個程序數(shù)據(jù)為一個TCP報文段，則是粘包；其中MSS = TCP報文段長度-TCP首部長度。在IP協(xié)議層或者鏈路層、物理層，都存在拆包、粘包現(xiàn)象。
解決粘包和拆包的方法主要有：
三、TCP可靠性傳輸：
1、TCP 如何保證可靠性傳輸：
（1）三次握手
（2）應答機制與超時重傳：TCP接收端收到發(fā)送端的數(shù)據(jù)時，它將發(fā)送一個確認。當TCP發(fā)送端發(fā)出一個報文段后，它會啟動一個定時器，等待接收端的確認報文段，如果不能及時收到一個確認，將重發(fā)這個報文段。
（3）數(shù)據(jù)包校驗與丟棄重復數(shù)據(jù)：TCP會檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出響應，這時TCP會超時重發(fā)數(shù)據(jù)；對于重復數(shù)據(jù)，則進行丟棄；
（4）對失序數(shù)據(jù)包進行重排序：既然TCP報文段作為IP數(shù)據(jù)報來傳輸，而IP數(shù)據(jù)報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數(shù)據(jù)進行重新排序，然后才交給應用層；
（5）流量控制：TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，防止較快主機致使較慢主機的緩沖區(qū)溢出。TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。
（6）擁塞控制：網(wǎng)絡(luò)擁塞時，減少數(shù)據(jù)的發(fā)送。
2、TCP的流量控制：
所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，讓接收方來得及接收。因為如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方可能會來不及接收，這就會造成數(shù)據(jù)的丟失。TCP的流量控制是通過大小可變的滑動窗口來實現(xiàn)的。接收端將自己可以接收的緩沖區(qū)大小放入TCP首部中的“窗口大小”字段，通過ACK報文來通知發(fā)送端，滑動窗口是接收端用來控制發(fā)送端發(fā)送數(shù)據(jù)的大小，從而達到流量控制
其實發(fā)送方的窗口上限，是取值擁塞窗口和滑動窗口兩者的最小值。當滑動窗口為 0 時，發(fā)送方一般不能再發(fā)送數(shù)據(jù)包，但有兩種情況除外，一種情況是可以發(fā)送緊急數(shù)據(jù)，例如，允許用戶終止在遠端機上的運行進程。另一種情況是發(fā)送方可以發(fā)送一個 1 字節(jié)的數(shù)據(jù)報來通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動窗口大小。
設(shè)A向B發(fā)送數(shù)據(jù)。在連接建立時，B告訴了A：“我的接收窗口是 rwnd = 400 ”(這里的 rwnd 表示 receiver window) 。因此，發(fā)送方的發(fā)送窗口不能超過接收方給出的接收窗口的數(shù)值。假設(shè)每一個報文段為100字節(jié)長，而數(shù)據(jù)報文段序號的初始值設(shè)為1。
從圖中可以看出，B進行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最后減到 rwnd = 0 ，即不允許發(fā)送方再發(fā)送數(shù)據(jù)了。這種使發(fā)送方暫停發(fā)送的狀態(tài)將持續(xù)到主機B重新發(fā)出一個新的窗口值為止。B向A發(fā)送的三個報文段都設(shè)置了 ACK = 1 ，只有在 ACK=1 時確認號字段才有意義。
3、TCP的擁塞控制：
擁塞控制就是防止過多的數(shù)據(jù)注入網(wǎng)絡(luò)中，使網(wǎng)絡(luò)中的路由器或鏈路不致過載。發(fā)送方維持一個擁塞窗口cwnd 的狀態(tài)變量。擁塞窗口的大小動態(tài)變化，取決于網(wǎng)絡(luò)的擁塞程度，發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡(luò)中的分組數(shù)。 擁塞控制的方法主要有以下幾種：慢啟動、擁塞避免、快重傳和快恢復。
（1）慢開始算法：當發(fā)送主機開始發(fā)送數(shù)據(jù)時，不要一開始就發(fā)送大量的數(shù)據(jù)，因為不清楚網(wǎng)絡(luò)的擁塞情況，而是試探一下網(wǎng)絡(luò)的擁塞情況，由小到大逐漸增大發(fā)送窗口。在開始發(fā)送報文段時先設(shè)置cwnd=1，使得發(fā)送方在開始時只發(fā)送一個報文段，然后每經(jīng)過一個傳輸輪次RTT，擁塞窗口 cwnd 就加倍。另外，為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個慢開始門限 ssthresh 狀態(tài)變量。
當 cwnd < ssthresh 時，使用上述的慢開始算法。
當 cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞控制避免算法。
當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。
（2）擁塞避免算法：讓擁塞窗口cwnd緩慢地增大，即每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。
無論在慢開始階段還是在擁塞避免階段，只要網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時的擁塞窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd 設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò)中的數(shù)據(jù)量，使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的數(shù)據(jù)處理完畢。過程圖如下：
（3）快重傳：快重傳要求接收方在收到一個失序的報文段后就立即發(fā)出重復確認（使發(fā)送方及早知道有報文段沒有到達對方）而不必等到自己發(fā)送數(shù)據(jù)時捎帶確認。發(fā)送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待設(shè)置的重傳計時器時間到期。
接收方收到了M1和M2后都分別發(fā)出了確認?，F(xiàn)在假定接收方?jīng)]有收到M3但接著收到了M4。顯然，接收方不能確認M4，因為M4是收到的失序報文段。根據(jù)可靠傳輸原理，接收方可以什么都不做，也可以在適當時機發(fā)送一次對M2的確認。但按照快重傳算法的規(guī)定，接收方應及時發(fā)送對M2的重復確認，這樣做可以讓 發(fā)送方及早知道報文段M3沒有到達接收方。發(fā)送方接著發(fā)送了M5和M6。接收方收到這兩個報文后，也還要再次發(fā)出對M2的重復確認。這樣，發(fā)送方共收到了 接收方的四個對M2的確認，其中后三個都是重復確認。
（4）快恢復：與快重傳配合使用的還有快恢復算法，當發(fā)送方連續(xù)收到三個重復確認時，就執(zhí)行“乘法減少”算法，把ssthresh門限設(shè)置為擁塞窗口cwnd的一半，但是接下去并不執(zhí)行慢開始算法，而是將cwnd設(shè)置為ssthresh的大小，然后執(zhí)行擁塞避免算法：因為如果網(wǎng)絡(luò)出現(xiàn)擁塞的話，就不會收到好幾個重復的確認，所以發(fā)送方現(xiàn)在認為網(wǎng)絡(luò)可能沒有出現(xiàn)擁塞，所以此時并不執(zhí)行慢開始算法，而是執(zhí)行擁塞避免算法。
4、擁塞控制和流量控制的差別：
（1）相同點：擁塞控制和流量控制的相同點都是控制丟包現(xiàn)象，實現(xiàn)機制都是讓發(fā)送方發(fā)得慢一點。
（2）不同點：
① 擁塞控制是一個全局性的過程，防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，造成網(wǎng)絡(luò)擁塞
② 流量控制指點對點通信量的控制，要做的就是控制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接受。
應用層：
應用層主要提供應用進程間的網(wǎng)絡(luò)通信服務(wù)，完成用戶請求的各種服務(wù)。
一、http協(xié)議：
http協(xié)議即超文本傳輸協(xié)議，基于TCP協(xié)議，用于從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。http協(xié)議是無狀態(tài)協(xié)議，自身不對請求和響應直接的通信狀態(tài)進行保存，但有些場景下我們需要保存用戶的登陸信息，所以引入了cookie 和 session 來管理狀態(tài)。
1、cookie 和 session 的區(qū)別：
（1）保存位置與安全性：cookie保存在客戶端，session保存在服務(wù)端，所以在安全性上面，cookie存在安全隱患，可以通過攔截或本地文件找到cookie后進行攻擊，而session相對更加安全。因此，可以將登陸信息等重要信息存放為session中；其他信息如果需要保留，可以放在cookie中。
（2）存儲容量：單個cookie最大只允許4KB，一個站點最多保存20個Cookie；session沒有大小限制，個數(shù)只跟服務(wù)器的內(nèi)存大小有關(guān)。
（3）有效期與實現(xiàn)機制：cookie可長期有效存在；session依賴于cookie，過期時間默認為-1，只需關(guān)閉窗口該 session 就會失效。每個客戶端對應一個session ，客戶端之間的 session 相互獨立；
cookie：cookie是一小段的文本信息，當客戶端請求服務(wù)器時，如果服務(wù)器需要記錄該用戶狀態(tài)，就在響應頭中向客戶端瀏覽器頒發(fā)一個Cookie，而客戶端瀏覽器會把cookie保存起來。當再次請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)站連同該cookie一起提交給服務(wù)器，服務(wù)器會檢查該cookie，以此來辨認用戶狀態(tài)。
session：當客戶端請求服務(wù)器時，都會帶上cookie，cookie里面一般都會有一個JSESSIONID，服務(wù)器就按照 JSESSIONID 來找到對應的 session；如果客戶端請求不包含 JSESSIONID，則為此客戶端創(chuàng)建session并生成相關(guān)聯(lián)的JSESSIONID，并將這個JSESSIONID在本次響應中返回給客戶端保存。客戶端保存這個 JSESSIONID 的方式可以使用cookie機制。若瀏覽器禁用Cookie的話，可以通過 URL重寫機制 將JSESSIONID傳回服務(wù)器。
2、一個完整的http請求是怎么樣？即從輸入網(wǎng)址到獲得頁面的過程：
（1）解析url，獲取 url 中包含的域名；
（2）通過DNS系統(tǒng)查詢域名對應的IP；
DNS服務(wù)器大致分為三種類型：根DNS服務(wù)器、頂級域DNS服務(wù)器 和 權(quán)威DNS服務(wù)器，其中： 頂級域DNS服務(wù)器主要負責諸如com、org、net、edu、gov 等頂級域名。
根DNS服務(wù)器存儲了所有 頂級域DNS服務(wù)器的 IP 地址，可以通過根服務(wù)器找到頂級域服務(wù)器（例如：www.baidu.com，根服務(wù)器會返回所有維護 com 這個頂級域服務(wù)器的 IP 地址）。然后你任選其中一個頂級域服務(wù)器發(fā)送請求，該頂級域服務(wù)器拿到域名后能夠給出負責當前域的權(quán)威服務(wù)器地址（以 baidu為例的話，頂級域服務(wù)器將返回所有負責 baidu 這個域的權(quán)威服務(wù)器地址）。接著任選其中一個權(quán)威服務(wù)器地址查詢 「www.baidu.com」 的具體 IP 地址，最終權(quán)威服務(wù)器會返回給你具體的 IP 地址。此外，本地 DNS 服務(wù)器是具有緩存功能的，通常兩天內(nèi)的記錄都會被緩存。
所以，通過DNS系統(tǒng)查詢域名對應的 IP 的具體步驟可以總結(jié)為：
① 操作系統(tǒng)先查本地 hosts文件 中是否有記錄，如果有，則直接返回相對應映射的IP地址。
② 如果本地hosts文件中沒有配置，則主機向自己的本地 DNS 服務(wù)器 發(fā)送查詢報文，如果本地DNS服務(wù)器緩存中有，將直接返回結(jié)果
③ 如果本地服務(wù)器緩存中沒有，則從內(nèi)置在內(nèi)部的根服務(wù)器列表（全球13臺，固定的IP地址）中選一個發(fā)送查詢報文
④ 根服務(wù)器解析域名中的后綴名，告訴本地服務(wù)器負責該后綴名的所有頂級服務(wù)器列表
⑤ 本地服務(wù)器選擇其中一個頂級域服務(wù)器發(fā)送查詢請求，頂級域服務(wù)器拿到域名后繼續(xù)解析，返回對應域的所有權(quán)威服務(wù)器列表
⑥ 本地服務(wù)器再向返回的權(quán)威服務(wù)器發(fā)送查詢報文，最終會從某一個權(quán)威服務(wù)器上得到具體的 IP 地址
⑦ 主機返回結(jié)果IP
（3）瀏覽器得到域名對應的IP地址之后，向服務(wù)器發(fā)起三次握手請求建立TCP鏈接；
（4）TCP鏈接鏈接建立起來后，瀏覽器向服務(wù)器發(fā)送http請求，如果 html文件在緩存里，瀏覽器則直接返回， 如果沒有，則去后臺拿；
① 瀏覽器首次加載資源成功時，服務(wù)器返回200，此時瀏覽器不僅將資源下載下來，而且把response的header(里面的date屬性非常重要，用來計算第二次相同資源時當前時間和date的時間差)一并緩存;
② 下一次加載資源時，首先要經(jīng)過強緩存的處理，cache-control的優(yōu)先級最高，比如cache-control：no-cache,就直接進入到協(xié)商緩存的步驟了，如果cache-control：max-age=xxx,就會先比較當前時間和上一次返回200時的時間差，如果沒有超過max-age，命中強緩存，不發(fā)請求直接從本地緩存讀取該文件（這里需要注意，如果沒有cache-control，會取expires的值，來對比是否過期），過期的話會進入下一個階段，協(xié)商緩存
③ 協(xié)商緩存階段，則向服務(wù)器發(fā)送header帶有If-None-Match和If-Modified-Since的請求，服務(wù)器會比較Etag，如果相同，命中協(xié)商緩存，返回304；如果不一致則有改動，直接返回新的資源文件帶上新的Etag值并返回200;
④ 協(xié)商緩存第二個重要的字段是，If-Modified-Since，如果客戶端發(fā)送的If-Modified-Since的值跟服務(wù)器端獲取的文件最近改動的時間，一致則命中協(xié)商緩存，返回304；不一致則返回新的last-modified和文件并返回200;
（5）服務(wù)器接收到請求后，根據(jù)路徑參數(shù)映射到特定的處理器進行處理，并將處理結(jié)果以及相應的視圖返回給瀏覽器。
（6）瀏覽器解析視圖，并根據(jù)請求到的資源、數(shù)據(jù)進行渲染頁面，最終向用戶呈現(xiàn)一個完整的頁面。
構(gòu)建DOM樹(DOM tree)：從上到下解析HTML文檔生成DOM節(jié)點樹（DOM tree），也叫內(nèi)容樹（content tree）；
構(gòu)建CSSOM(CSS Object Model)樹：加載解析樣式生成CSSOM樹；
執(zhí)行JavaScript：加載并執(zhí)行JavaScript代碼（包括內(nèi)聯(lián)代碼或外聯(lián)JavaScript文件）；
構(gòu)建渲染樹(render tree)：根據(jù)DOM樹和CSSOM樹,生成渲染樹(render tree)；
渲染樹：按順序展示在屏幕上的一系列矩形，這些矩形帶有字體，顏色和尺寸等視覺屬性。
布局（layout）：根據(jù)渲染樹將節(jié)點樹的每一個節(jié)點布局在屏幕上的正確位置；
繪制（painting）：遍歷渲染樹繪制所有節(jié)點，為每一個節(jié)點適用對應的樣式，這一過程是通過UI后端模塊完成；
3、http的長連接和短連接？
http的長連接和短連接本質(zhì)上是TCP長連接和短連接。從http1.1開始就默認使用長連接。
短鏈接是指客戶端與服務(wù)端每進行一次請求操作，就建立一次TCP連接，收到服務(wù)器響應后，就斷開連接。
長連接是指客戶端和服務(wù)建立TCP連接后，它們之間的連接會持續(xù)存在，不會因為一次HTTP請求后關(guān)閉，后續(xù)的請求也是用這個連接進行通信，使用長連接的HTTP協(xié)議，會在響應頭有加入：Connection:keep-alive。長連接可以省去每次TCP建立和關(guān)閉的握手和揮手操作，節(jié)約時間提高效率。但在長連接下，客戶端一般不會主動關(guān)閉連接，如果客戶端和服務(wù)端之間的連接一直不關(guān)閉的話，隨著連接數(shù)越來越多，會對服務(wù)端造成壓力。
所以長連接多用于頻繁請求資源，而且連接數(shù)不能太多的情況，例如數(shù)據(jù)庫的連接用長連接。而像Web網(wǎng)站這種并發(fā)量大，但是每個用戶無需頻繁操作的場景，一般都使用短連接，因為長連接對服務(wù)端來說會耗費一定的資源。
4、http的斷點續(xù)傳是如何實現(xiàn)的？
HTTP請求頭有個Range字段；我們下載文件的時候如果遇到網(wǎng)絡(luò)中斷，如果重頭開始下載會浪費時間，所以我們可以從上一次中斷處繼續(xù)開始下載；具體的操作：
Range: bytes=5001-10000
或者指定5001以后的所有數(shù)據(jù)
Range: bytes=5001-
5、http存在的問題：
通信使用明文不加密，通信內(nèi)容可能被竊聽；
無法驗證報文的完整性，數(shù)據(jù)內(nèi)容可能被篡改
不驗證通信方身份、可能遭到偽裝，無法保證數(shù)據(jù)發(fā)送到正確的機器上；
為了解決上述幾個問題，那么就引入了https協(xié)議。
二、https協(xié)議：
https 是基于tcp協(xié)議，在http的基礎(chǔ)上加入了SSL/TLS，可看成是添加了加密和認證機制的http，使用對稱加密、非對稱加密、證書等技術(shù)進行進行客戶端與服務(wù)端的數(shù)據(jù)加密傳輸，最終達到保證整個通信的安全性。
對稱加密指加密和解密都使用同一個密鑰的方式，這種方式存在如何安全地將密鑰發(fā)送對方的問題；非對稱加密使用兩個密鑰，公鑰加密則需要私鑰解密，私鑰加密則需要公鑰解密。不能私鑰加密，私鑰解密。非對稱加密不需要發(fā)送用來解密的私鑰，所以可以保證安全性，但是和對稱加密比起來，速度非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發(fā)送出去。
1、https的認證加密過程？如何保證內(nèi)容不會被篡改的？
（1）https是基于tcp協(xié)議的，首先客戶端會和服務(wù)端發(fā)起鏈接建立
（2）服務(wù)端返回它的證書給客戶端，證書中包含了服務(wù)端公鑰S.pub、頒發(fā)機構(gòu)和有效期等信息
（3）客戶端通過瀏覽器內(nèi)置的根證書（內(nèi)部包含CA機構(gòu)的公鑰C.pub）驗證證書的合法性
（4）客戶端生成隨機的對稱加密密鑰Z，然后通過服務(wù)端的公鑰S.pub加密發(fā)送給服務(wù)端
（5）客戶端和服務(wù)端之后就通過對稱加密密鑰Z加密數(shù)據(jù)來進行http通信
2、根證書如何保證簽發(fā)的證書是安全有效的？
（1）服務(wù)器會預先生成非對稱加密密鑰，私鑰S.pri自己保留，而公鑰S.pub則發(fā)送給CA進行簽名認證
（2）CA機構(gòu)也會預先生成非對稱加密密鑰，其私鑰C.pri用來對服務(wù)器的公鑰S.pub進行簽名，生成CA證書
（3）CA機構(gòu)將簽名生成的CA證書返回給服務(wù)器，也就是前面服務(wù)端給客戶端那個證書
（4）因為CA機構(gòu)比較權(quán)威，所以很多瀏覽器會內(nèi)置包含它公鑰C.pub的證書，稱之為根證書，然后可以使用根證書來驗證其頒發(fā)證書的合法性了
在整個過程中，一共涉及2對公私密鑰對，一對由服務(wù)器產(chǎn)生，主要用于加密，一對由CA產(chǎn)生，主要用于簽名。
3、為什么需要CA證書認證機構(gòu)呢？
CA證書是為了確保服務(wù)端的公鑰是準確無誤、沒有被修改過的。雖然https是加密的，但是請求還是可以被攔截的，假設(shè)沒有CA證書，如果服務(wù)器返回的包含公鑰的包被攻擊者截取，然后攻擊者也生成一對公私鑰，他將自己的公鑰發(fā)給客戶端。攻擊者得到客戶端數(shù)據(jù)后進行解密，然后再通過服務(wù)器的公鑰加密發(fā)給服務(wù)器，這樣數(shù)據(jù)就被攻擊者獲取到了。
有了CA證書后，客戶端根據(jù)內(nèi)置的CA根證書，很容易識別出攻擊者的公鑰不合法，或者說攻擊者的證書不合法。
證書通常包含這些內(nèi)容：(1) 服務(wù)端的公鑰；(2) 證書發(fā)行者(CA)對證書的數(shù)字簽名；(3) 證書所用的簽名算法；(4) 證書發(fā)布機構(gòu)、有效期、所有者的信息等其他信息
三、http 的請求與響應：
1、http的常見請求方式：
（1）get：向服務(wù)端獲取資源，所以查詢操作一般用get
（2）post：向服務(wù)端提交請求字段，創(chuàng)建操作使用 post，該操作不是冪等的，多次執(zhí)行會導致多條數(shù)據(jù)被創(chuàng)建
（3）put：修改指定URL的資源，如果資源不存在，則進行創(chuàng)建，修改操作一般使用 put，在http中，put 被定義成冪等的，多次操作會導致前面的數(shù)據(jù)被覆蓋
（4）patch：局部修改URL所在資源的數(shù)據(jù)，是對put的補充
（5）delete：刪除指定URL的資源。
（6）head：獲取響應報文的首部，即獲得URL資源的頭部
（7）options：詢問服務(wù)器支持哪些方法，響應頭中返回 Allow: GET、POST、HEAD
（8）trace：追蹤路徑，主要用于測試或診斷；在請求頭中在Max-Forwards字段設(shè)置數(shù)字，每經(jīng)過一個服務(wù)器該數(shù)字就減一，當?shù)?的時候就直接返回，一般通過該方法檢查請求發(fā)送出去是否被篡改
2、get和 post 請求的區(qū)別：
（1）功能：get一般用來從服務(wù)器上面獲取資源，post一般用來更新服務(wù)器上面的資源。
（2）冪等性：get 是冪等的，post 為非冪等的
（3）安全性：get 請求的參數(shù)會明文附加在URL之后，而 post 請求提交的數(shù)據(jù)則被封裝到請求體中，相對更安全。
（4）傳輸數(shù)據(jù)量的大小：get請求允許發(fā)送的數(shù)據(jù)量比較小，大多數(shù)瀏覽器都會限制請求的url長度在2048個字節(jié)，而大多數(shù)服務(wù)器最多處理64K大小的url；而post請求提交的數(shù)據(jù)量則是沒有大小限制的。
（5）參數(shù)的數(shù)據(jù)類型：GET只接受ASCII字符，而POST沒有限制。
（6）GET在瀏覽器回退時是無害的，而POST會再次提交請求。
（7）get請求可以被緩存，可以被保留在瀏覽器的歷史記錄中；post請求不會被緩存，不會被保留在瀏覽器的歷史記錄中。
3、http報文頭分析：
（1）報文類型：報文類型分為請求報文和響應報文
① 請求報文包含三部分：
請求行：包含請求方法、URI、HTTP版本信息
請求首部字段
請求內(nèi)容實體
② 響應報文包含三部分：
（2）報文中各部分的簡要描述：
方法(method)：客戶端希望服務(wù)器對資源執(zhí)行的動作，是一個單獨的詞，比如：get 或者 post
請求URL(request-URL)：請求URL是資源的絕對路徑，服務(wù)器可以假定自己是URL的主機/端口
版本(version)：報文所使用的Http版本，其格式：HTTP/<主要版本號>.<次要版本號>
狀態(tài)碼(status-code)：標識請求過程中所發(fā)生的情況
原因短語(reason-phrase)：數(shù)字狀態(tài)碼的可讀版本，包含行終止序列之前的所有文本。
請求頭部(header)：可以有零個或多個頭部，每個首部都包含一個名字，后面跟著一個冒號(:)，然后是一個可選的空格，接著是一個值，最后是一個CRLF首部是由一個空行(CRLF)結(jié)束的，表示了頭部列表的結(jié)束和實體主體部分的開始
實體的主體部分(entity-body)：實體的主體部分包含一個由任意數(shù)據(jù)組成的數(shù)據(jù)塊，并不是所有的報文都包含實體的主體部分，有時，報文只是以一個CRLF結(jié)束。
（3）通用頭部：既可以出現(xiàn)在請求報文中，也可以出現(xiàn)在響應報文中，它提供了與報文相關(guān)的最基本的信息：
Connection：允許客戶端和服務(wù)器指定與請求/響應連接有關(guān)的選項，http1.1之后默認是 keep-alive
Date：日期和時間標志，說明報文是什么時間創(chuàng)建的
Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式
Cache-Control：用于隨報文傳送緩存指示
（4）請求頭部：請求頭部是只在請求報文中有意義的頭部。用于說明是誰或什么在發(fā)送請求、請求源自何處，或者客戶端的喜好及能力
Host：給出了接收請求的服務(wù)器的主機名和端口號
Referer：提供了包含當前請求URI的文檔的URL
User-Agent：將發(fā)起請求的應用程序名稱告知服務(wù)器
Accept：告訴服務(wù)器能夠發(fā)送哪些媒體類型
Accept-Encoding：告訴服務(wù)器能夠發(fā)送哪些編碼方式
Accept-Language：告訴服務(wù)器能夠發(fā)送哪些語言
Range：如果服務(wù)器支持范圍請求，就請求資源的指定范圍
If-Range：允許對文檔的某個范圍進行條件請求
Authorization：包含了客戶端提供給服務(wù)器，以便對其自身進行認證的數(shù)據(jù)
Cookie：客戶端用它向服務(wù)器傳送數(shù)據(jù)
（5）響應頭部：響應頭部為客戶端提供了一些額外信息，比如誰在發(fā)送響應、響應者的功能，甚至與響應相關(guān)的一些特殊指令
Age：(從最初創(chuàng)建開始)響應持續(xù)時間
Server：服務(wù)器應用程序軟件的名稱和版本
Accept-Ranges：對此資源來說，服務(wù)器可接受的范圍類型
Set-Cookie：在客戶端設(shè)置數(shù)據(jù)，以便服務(wù)器對客戶端進行標識
（6）實體首部：描述主體的長度和內(nèi)容，或者資源自身
Allow：列出了可以對此實體執(zhí)行的請求方法
Location：告知客戶端實體實際上位于何處，用于將接收端定向到資源的位置(URL)上去
Content-Base：解析主體中的相對URL時使用的基礎(chǔ)URL
Content-Encoding：對主體執(zhí)行的任意編碼方式
Content-Language：理解主體時最適宜使用的自然語言
Content-Length：主體的長度
Content-Type：這個主體的對象類型
ETag：與此實體相關(guān)的實體標記
Last-Modified：這個實體最后一次被修改的日期和時間
（7）實體的主體部分：該部分其實就是HTTP要傳輸?shù)膬?nèi)容，是可選的。HTTP報文可以承載很多類型的數(shù)字數(shù)據(jù)，比如，圖片、視頻、HTML文檔電子郵件、軟件應用程序等等。
4、Http 常見的狀態(tài)碼：
（1）1xx：請求處理中，請求已被接受，正在處理。
（2）2xx：請求成功，請求被成功處理。
200 ：OK，客戶端請求成功；
204（請求處理成功，但是沒有資源返回）
（3）3xx：重定向，要完成請求必須進一步處理。
（4）4xx：客戶端錯誤，請求不合法。
（5）5xx：服務(wù)端錯誤，服務(wù)端不能處理合法請求。
5、http/1.1和http/2.0的區(qū)別：
（1）多路復用，做到同一個連接并發(fā)處理多個請求：HTTP2.0 使用了多路復用的技術(shù)，做到同一個連接并發(fā)處理多個請求，并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級。
（2）支持首部壓縮：HTTP2.0使用HPACK算法對header的數(shù)據(jù)進行壓縮，這樣數(shù)據(jù)體積小了，在網(wǎng)絡(luò)上傳輸就會更快。
（3）服務(wù)器推送：當向支持HTTP2.0的web服務(wù)器請求時，服務(wù)器會順便把客戶端需要的資源一起推送到客戶端，避免客戶端再次創(chuàng)建連接發(fā)送請求到服務(wù)器端獲取，這種方式非常合適加載靜態(tài)資源。
（4）http2.0采用二進制而不是文本格式
6、http 和 https 的區(qū)別：
（1）http 和 https 都是基于 TCP 協(xié)議，但是 http 是使用明文傳輸，通訊內(nèi)容可能被竊聽和篡改，客戶端也無法驗證通訊方的身份，無法保證數(shù)據(jù)發(fā)送到正確的機器上；https 是在 http 的基礎(chǔ)上加入了 SSL/TLS，可看成是添加了加密和認證機制的http，使用對稱加密、非對稱加密、證書等技術(shù)進行進行客戶端與服務(wù)端的數(shù)據(jù)加密傳輸，最終達到保證整個通信的安全性。
（2）端口不同：http 使用的是80端口，https 使用的443端口
（3）資源消耗：和 http 通信相比，https通信會由于加解密處理消耗更多的CPU和內(nèi)存資源
四、應用層其他相關(guān)的協(xié)議：
（1）DNS域名系統(tǒng)：用于域名解析服務(wù)，將域名地址轉(zhuǎn)換為IP地址，基于UDP服務(wù)，使用53端口。
DNS底層既使用TCP又使用UDP協(xié)議：
① 域名解析時使用UDP協(xié)議：客戶端向DNS服務(wù)器查詢域名，一般返回的內(nèi)容都不超過512字節(jié)，用UDP傳輸即可，不用經(jīng)過TCP三次握手，這樣DNS服務(wù)器負載更低，響應更快。
② 區(qū)域傳送時使用TCP，主要有一下兩點考慮：
輔域名服務(wù)器會定時（一般時3小時）向主域名服務(wù)器進行查詢以便了解數(shù)據(jù)是否有變動。如有變動，則會執(zhí)行一次區(qū)域傳送，進行數(shù)據(jù)同步。區(qū)域傳送將使用TCP而不是UDP，因為數(shù)據(jù)同步傳送的數(shù)據(jù)量比一個請求和應答的數(shù)據(jù)量要多得多。
TCP是一種可靠的連接，保證了數(shù)據(jù)的準確性。
（2）FTP：定義了文件傳輸協(xié)議，使用21端口。上傳下載文件，都要用到FTP服務(wù)。
（3）Telnet：遠程終端協(xié)議，它是一種用于遠程登陸的端口，用戶可以以自己的身份遠程連接到計算機上，提供一種基于DOS模式下的通信服務(wù)。
（4）SMTP：定義了簡單郵件傳送協(xié)議，用于發(fā)送郵件，使用25號端口。
（5）POP3：與SMTP對應，POP3用于接收郵件。使用110端口。
（6）SNMP：簡單網(wǎng)絡(luò)管理協(xié)議，使用161號端口，是用來管理網(wǎng)絡(luò)設(shè)備的。
（7）TFTP(Trival File Transfer Protocal)：簡單文件傳輸協(xié)議，該協(xié)議在69端口上使用UDP服務(wù)。
版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接和本聲明。
本文鏈接：
https://blog.csdn.net/a745233700/article/details/114824602
