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