文章目錄

• 一、交換機(jī)工作原理
• 二、路由
• 三、DHCP
• 四、TCP和UDP的區(qū)別：
• 五、DNS
• 六、ARP工作原理
• 七、Ping和Traceroute
• 七、三次握手和四次揮手
• • • 三次握手的本質(zhì)是確認(rèn)通信雙方收發(fā)數(shù)據(jù)的能力
    • 四次揮手的目的是關(guān)閉一個連接
• 八、常見問題
• • • 1、為什么TCP連接的時候是3次？2次不可以嗎？
    • 2、為什么TCP連接的時候是3次，關(guān)閉的時候卻是4次？
    • 3、為什么客戶端發(fā)出第四次揮手的確認(rèn)報文后要等2MSL的時間才能釋放TCP連接？
    • 4、如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
    • 5、什么是HTTP，HTTP 與 HTTPS 的區(qū)別
    • 6、常用HTTP狀態(tài)碼
    • 6、GET和POST區(qū)別
    • 7、什么是對稱加密與非對稱加密
    • 8、什么是HTTP2
    • 9、Session、Cookie和Token的主要區(qū)別
    • 10、Servlet是線程安全的嗎
    • 11、如果客戶端禁止 cookie 能實現(xiàn) session 還能用嗎？
• 九、TCP11種狀態(tài)

一、交換機(jī)工作原理

根據(jù)源MAC地址學(xué)習(xí)，根據(jù)目標(biāo)MAC地址轉(zhuǎn)發(fā)
除源端口外的端口廣播未知數(shù)據(jù)幀

接收方回應(yīng)
交換機(jī)實現(xiàn)單播通信

更新：老化時間300秒
交換機(jī)對應(yīng)端口的MAC 地址發(fā)生變化時

二、路由

路由:跨越從源主機(jī)到目標(biāo)主機(jī)的一個互聯(lián)網(wǎng)絡(luò)來轉(zhuǎn)發(fā)數(shù)據(jù)包的過程。

路由表：路由器根據(jù)路由表做路徑選擇

路由器的工作原理:根據(jù)路由表選擇最佳路徑,每個路由器都維護(hù)著一張路由表,這是路由器轉(zhuǎn)發(fā)數(shù)據(jù)包的關(guān)鍵,每條路由表記錄指明了到達(dá)某個子網(wǎng)或主機(jī)應(yīng)從路由器的哪個物理端口發(fā)送,通過此端口可到達(dá)該路徑的下一個路由器的地址。

三、DHCP

基本原理:

第一步:客戶端通過廣播發(fā)送DHCP Discover報文尋找服務(wù)器端

第二步:服務(wù)器端通過單播發(fā)送DHCP Offer報文向客戶端提供IP地址等網(wǎng)絡(luò)信息

第三步:客戶端通過廣播發(fā)送DHCP Request報文告知服務(wù)器端本地選擇使用哪個IP地址第四步:服務(wù)器通過單播發(fā)送DHCP Ack報文告知客戶端lP地址是合法可用的

四、TCP和UDP的區(qū)別：

UDPTCP

是否連接	無連接	面向連接
是否可靠	不可靠傳輸，不使用流量控制和擁塞控制	可靠傳輸，使用流量控制和擁塞控制
連接對象個數(shù)	支持一對一，一對多，多對一和多對多交互通信	只能是一對一通信
傳輸方式	面向報文	面向字節(jié)流
首部開銷	首部開銷小，僅8字節(jié)	首部最小20字節(jié)，最大60字節(jié)
場景	適用于實時應(yīng)用（IP電話、視頻會議、直播等）	適用于要求可靠傳輸?shù)膽?yīng)用，例如文件傳輸

TCP:可靠的、面向連接的傳輸層協(xié)議。主要它有三次握手、四次斷開、窗口滑動、數(shù)據(jù)分段、數(shù)據(jù)重組、數(shù)據(jù)重傳機(jī)制保證數(shù)據(jù)的可靠性。。

UDP:不可靠的、面向無連接的傳輸層協(xié)議。它沒有什么機(jī)制保證數(shù)據(jù)可靠性,當(dāng)數(shù)據(jù)量非常龐大時可以通過此協(xié)議來保證數(shù)據(jù)的高效低延時。。

以tcp/ip協(xié)議為核心,分五層。tcp工作在第4層，主要有tcp和udp協(xié)議。其中tcp是可靠協(xié)議，udp是不可靠協(xié)議。 tcp傳輸之前，需要建立連接，通過三次握手實現(xiàn)。

每一個應(yīng)用層（TCP/IP參考模型的最高層）協(xié)議一般都會使用到兩個傳輸層協(xié)議之一：

運行在TCP協(xié)議上的協(xié)議：

• HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議），主要用于普通瀏覽。
• HTTPS（HTTP over SSL，安全超文本傳輸協(xié)議）,HTTP協(xié)議的安全版本。
• FTP（File Transfer Protocol，文件傳輸協(xié)議），用于文件傳輸。
• POP3（Post Office Protocol, version 3，郵局協(xié)議），收郵件用。
• SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協(xié)議），用來發(fā)送電子郵件。
• TELNET（Teletype over the Network，網(wǎng)絡(luò)電傳），通過一個終端（terminal）登陸到網(wǎng)絡(luò)。
• SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陸用。

運行在UDP協(xié)議上的協(xié)議：

• BOOTP（Boot Protocol，啟動協(xié)議），應(yīng)用于無盤設(shè)備。
• NTP（Network Time Protocol，網(wǎng)絡(luò)時間協(xié)議），用于網(wǎng)絡(luò)同步。
• DHCP（Dynamic Host Configuration Protocol，動態(tài)主機(jī)配置協(xié)議），動態(tài)配置IP地址。

運行在TCP和UDP協(xié)議上：

• DNS（Domain Name Service，域名服務(wù)），用于完成地址查找，郵件轉(zhuǎn)發(fā)等工作。

五、DNS

默認(rèn)端口為53。

DNS端口分為TCP和UDP。DNS協(xié)議運行在UDP協(xié)議之上

一、TCP是用來做區(qū)域傳送

二、UDP是用來做DNS解析的。

六、ARP工作原理

每臺主機(jī)都會在自己的ARP緩沖區(qū)中建立一個 ARP列表，以表示IP地址和MAC地址的對應(yīng)關(guān)系。

當(dāng)源主機(jī)需要將一個數(shù)據(jù)包要發(fā)送到目的主機(jī)時，會首先檢查自己 ARP列表中是否存在該 IP地址對應(yīng)的MAC地址。

如果有，就直接將數(shù)據(jù)包發(fā)送到這個MAC地址；如果沒有，就向本地網(wǎng)段發(fā)起一個ARP請求的廣播包，查詢此目的主機(jī)對應(yīng)的MAC地址。

此ARP請求數(shù)據(jù)包里包括源主機(jī)的IP地址、硬件地址、以及目的主機(jī)的IP地址。網(wǎng)絡(luò)中所有的主機(jī)收到這個ARP請求后，會檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。

如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中。

如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個 ARP響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的MAC地址。

源主機(jī)收到這個ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。

如果源主機(jī)一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

七、Ping和Traceroute

https://blog.csdn.net/tomatolee221/article/details/89531048

七、三次握手和四次揮手

三次握手的本質(zhì)是確認(rèn)通信雙方收發(fā)數(shù)據(jù)的能力

1.發(fā)送方向接收方發(fā)送SYN請求

⒉接收方接收到此請求后會主動回復(fù)一個ACK，并且同時也發(fā)送一個SYN請求

3.發(fā)送方接收到接收方發(fā)來的SYN請求后，給出一個ACK確認(rèn)。。

四次揮手的目的是關(guān)閉一個連接

1.發(fā)送方向接收方發(fā)送一個FIN請求

⒉接收方收到此請求后給出一個ACK確認(rèn)（半關(guān)閉狀態(tài)）

3.接收方發(fā)送一個FIN請求給發(fā)送方

4.發(fā)送方收到接收方的FIN請求后，回復(fù)一個ACK。

八、常見問題

1、為什么TCP連接的時候是3次？2次不可以嗎？

因為需要考慮連接時丟包的問題，如果只握手2次，第二次握手時如果服務(wù)端發(fā)給客戶端的確認(rèn)報文段丟失，此時服務(wù)端已經(jīng)準(zhǔn)備好了收發(fā)數(shù)(可以理解服務(wù)端已經(jīng)連接成功)據(jù)，而客戶端一直沒收到服務(wù)端的確認(rèn)報文，所以客戶端就不知道服務(wù)端是否已經(jīng)準(zhǔn)備好了(可以理解為客戶端未連接成功)，這種情況下客戶端不會給服務(wù)端發(fā)數(shù)據(jù)，也會忽略服務(wù)端發(fā)過來的數(shù)據(jù)。

如果是三次握手，即便發(fā)生丟包也不會有問題，比如如果第三次握手客戶端發(fā)的確認(rèn)ack報文丟失，服務(wù)端在一段時間內(nèi)沒有收到確認(rèn)ack報文的話就會重新進(jìn)行第二次握手，也就是服務(wù)端會重發(fā)SYN報文段，客戶端收到重發(fā)的報文段后會再次給服務(wù)端發(fā)送確認(rèn)ack報文。

2、為什么TCP連接的時候是3次，關(guān)閉的時候卻是4次？

因為只有在客戶端和服務(wù)端都沒有數(shù)據(jù)要發(fā)送的時候才能斷開TCP。而客戶端發(fā)出FIN報文時只能保證客戶端沒有數(shù)據(jù)發(fā)了，服務(wù)端還有沒有數(shù)據(jù)發(fā)客戶端是不知道的。而服務(wù)端收到客戶端的FIN報文后只能先回復(fù)客戶端一個確認(rèn)報文來告訴客戶端我服務(wù)端已經(jīng)收到你的FIN報文了，但我服務(wù)端還有一些數(shù)據(jù)沒發(fā)完，等這些數(shù)據(jù)發(fā)完了服務(wù)端才能給客戶端發(fā)FIN報文(所以不能一次性將確認(rèn)報文和FIN報文發(fā)給客戶端，就是這里多出來了一次)。

3、為什么客戶端發(fā)出第四次揮手的確認(rèn)報文后要等2MSL的時間才能釋放TCP連接？

這里同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務(wù)端沒收到確認(rèn)ack報文就會重發(fā)第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這么長時間來確認(rèn)服務(wù)端確實已經(jīng)收到了。

4、如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP設(shè)有一個保活計時器，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

5、什么是HTTP，HTTP 與 HTTPS 的區(qū)別

HTTP 是一個在計算機(jī)世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范

區(qū)別HTTPHTTPS

協(xié)議	運行在 TCP 之上，明文傳輸，客戶端與服務(wù)器端都無法驗證對方的身份	身披 SSL( Secure Socket Layer )外殼的 HTTP，運行于 SSL 上，SSL 運行于 TCP 之上， 是添加了加密和認(rèn)證機(jī)制的 HTTP。
端口	80	443
資源消耗	較少	由于加解密處理，會消耗更多的 CPU 和內(nèi)存資源
開銷	無需證書	需要證書，而證書一般需要向認(rèn)證機(jī)構(gòu)購買
加密機(jī)制	無	共享密鑰加密和公開密鑰加密并用的混合加密機(jī)制
安全性	弱	由于加密機(jī)制，安全性強(qiáng)

6、常用HTTP狀態(tài)碼

HTTP狀態(tài)碼表示客戶端HTTP請求的返回結(jié)果、標(biāo)識服務(wù)器處理是否正常、表明請求出現(xiàn)的錯誤等。

狀態(tài)碼的類別：

類別原因短語

1XX	Informational（信息性狀態(tài)碼） 接受的請求正在處理
2XX	Success（成功狀態(tài)碼） 請求正常處理完畢
3XX	Redirection（重定向狀態(tài)碼） 需要進(jìn)行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態(tài)碼） 服務(wù)器無法處理請求
5XX	Server Error（服務(wù)器錯誤狀態(tài)碼） 服務(wù)器處理請求出錯

常用HTTP狀態(tài)碼：

2XX成功（這系列表明請求被正常處理了）

200	OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理
204	No content，表示請求成功，但響應(yīng)報文不含實體的主體部分
206	Partial Content，進(jìn)行范圍請求成功

3XX重定向（表明瀏覽器要執(zhí)行特殊處理）

301	moved permanently，永久性重定向，表示資源已被分配了新的 URL
302	found，臨時性重定向，表示資源臨時被分配了新的 URL
303	see other，表示資源存在著另一個 URL，應(yīng)使用 GET 方法獲取資源（對于301/302/303響應(yīng)，幾乎所有瀏覽器都會刪除報文主體并自動用GET重新請求）
304	not modified，表示服務(wù)器允許訪問資源，但請求未滿足條件的情況（與重定向無關(guān)）
307	temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發(fā)出請求

4XX客戶端錯誤

400	bad request，請求報文存在語法錯誤
401	unauthorized，表示發(fā)送的請求需要有通過 HTTP 認(rèn)證的認(rèn)證信息
403	forbidden，表示對請求資源的訪問被服務(wù)器拒絕，可在實體主體部分返回原因描述
404	not found，表示在服務(wù)器上沒有找到請求的資源

5XX服務(wù)器錯誤

500	internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤
501	Not Implemented，表示服務(wù)器不支持當(dāng)前請求所需要的某個功能
503	service unavailable，表明服務(wù)器暫時處于超負(fù)載或正在停機(jī)維護(hù)，無法處理請求

6、GET和POST區(qū)別

說道GET和POST，就不得不提HTTP協(xié)議，因為瀏覽器和服務(wù)器的交互是通過HTTP協(xié)議執(zhí)行的，而GET和POST也是HTTP協(xié)議中的兩種方法。

HTTP全稱為Hyper Text Transfer Protocol，中文翻譯為超文本傳輸協(xié)議，目的是保證瀏覽器與服務(wù)器之間的通信。HTTP的工作方式是客戶端與服務(wù)器之間的請求-應(yīng)答協(xié)議。

HTTP協(xié)議中定義了瀏覽器和服務(wù)器進(jìn)行交互的不同方法，基本方法有4種，分別是GET，POST，PUT，DELETE。這四種方法可以理解為，對服務(wù)器資源的查，改，增，刪。

• GET：從服務(wù)器上獲取數(shù)據(jù)，也就是所謂的查，僅僅是獲取服務(wù)器資源，不進(jìn)行修改。
• POST：向服務(wù)器提交數(shù)據(jù)，這就涉及到了數(shù)據(jù)的更新，也就是更改服務(wù)器的數(shù)據(jù)。
• PUT：英文含義是放置，也就是向服務(wù)器新添加數(shù)據(jù)，就是所謂的增。
• DELETE：從字面意思也能看出，這種方式就是刪除服務(wù)器數(shù)據(jù)的過程。

GET和POST區(qū)別

Get是不安全的，因為在傳輸過程，數(shù)據(jù)被放在請求的URL中；Post的所有操作對用戶來說都是不可見的。 但是這種做法也不時絕對的，大部分人的做法也是按照上面的說法來的，但是也可以在get請求加上 request body，給 post請求帶上 URL 參數(shù)。

Get請求提交的url中的數(shù)據(jù)最多只能是2048字節(jié)，這個限制是瀏覽器或者服務(wù)器給添加的，http協(xié)議并沒有對url長度進(jìn)行限制，目的是為了保證服務(wù)器和瀏覽器能夠正常運行，防止有人惡意發(fā)送請求。Post請求則沒有大小限制。

Get限制Form表單的數(shù)據(jù)集的值必須為ASCII字符；而Post支持整個ISO10646字符集。

Get執(zhí)行效率卻比Post方法好。Get是form提交的默認(rèn)方法。

GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。

對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）；

而對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）。

7、什么是對稱加密與非對稱加密

對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發(fā)送問題，即如何安全地將密鑰發(fā)給對方；

而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發(fā)布，但私鑰只有自己知道。發(fā)送密文的一方使用對方的公鑰進(jìn)行加密處理，對方接收到加密信息后，使用自己的私鑰進(jìn)行解密。
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，非常的慢

8、什么是HTTP2

HTTP2 可以提高了網(wǎng)頁的性能。

在 HTTP1 中瀏覽器限制了同一個域名下的請求數(shù)量（Chrome 下一般是六個），當(dāng)在請求很多資源的時候，由于隊頭阻塞當(dāng)瀏覽器達(dá)到最大請求數(shù)量時，剩余的資源需等待當(dāng)前的六個請求完成后才能發(fā)起請求。

HTTP2 中引入了多路復(fù)用的技術(shù)，這個技術(shù)可以只通過一個 TCP 連接就可以傳輸所有的請求數(shù)據(jù)。多路復(fù)用可以繞過瀏覽器限制同一個域名下的請求數(shù)量的問題，進(jìn)而提高了網(wǎng)頁的性能。

9、Session、Cookie和Token的主要區(qū)別

HTTP協(xié)議本身是無狀態(tài)的。什么是無狀態(tài)呢，即服務(wù)器無法判斷用戶身份。

什么是cookie

cookie是由Web服務(wù)器保存在用戶瀏覽器上的小文件（key-value格式），包含用戶相關(guān)的信息。客戶端向服務(wù)器發(fā)起請求，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie。客戶端瀏覽器會把Cookie保存起來。當(dāng)瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶身份。

什么是session

session是依賴Cookie實現(xiàn)的。session是服務(wù)器端對象

session 是瀏覽器和服務(wù)器會話過程中，服務(wù)器分配的一塊儲存空間。服務(wù)器默認(rèn)為瀏覽器在cookie中設(shè)置 sessionid，瀏覽器在向服務(wù)器請求過程中傳輸 cookie 包含 sessionid ，服務(wù)器根據(jù) sessionid 獲取出會話中存儲的信息，然后確定會話的身份信息。

cookie與session區(qū)別

• 存儲位置與安全性：cookie數(shù)據(jù)存放在客戶端上，安全性較差，session數(shù)據(jù)放在服務(wù)器上，安全性相對更高；
• 存儲空間：單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie，session無此限制
• 占用服務(wù)器資源：session一定時間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多，占用服務(wù)器性能，考慮到服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。

什么是Token

Token的引入：Token是在客戶端頻繁向服務(wù)端請求數(shù)據(jù)，服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進(jìn)行對比，判斷用戶名和密碼正確與否，并作出相應(yīng)提示，在這樣的背景下，Token便應(yīng)運而生。

Token的定義：Token是服務(wù)端生成的一串字符串，以作客戶端進(jìn)行請求的一個令牌，當(dāng)?shù)谝淮蔚卿浐?#xff0c;服務(wù)器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。

使用Token的目的：Token的目的是為了減輕服務(wù)器的壓力，減少頻繁的查詢數(shù)據(jù)庫，使服務(wù)器更加健壯。

Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請求認(rèn)證，服務(wù)端認(rèn)證成功，那么在服務(wù)端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位

session與token區(qū)別

• session機(jī)制存在服務(wù)器壓力增大，CSRF跨站偽造請求攻擊，擴(kuò)展性不強(qiáng)等問題；
• session存儲在服務(wù)器端，token存儲在客戶端
• token提供認(rèn)證和授權(quán)功能，作為身份認(rèn)證，token安全性比session好；
• session這種會話存儲方式方式只適用于客戶端代碼和服務(wù)端代碼運行在同一臺服務(wù)器上，token適用于項目級的前后端分離（前后端代碼運行在不同的服務(wù)器下）

10、Servlet是線程安全的嗎

Servlet不是線程安全的，多線程并發(fā)的讀寫會導(dǎo)致數(shù)據(jù)不同步的問題。

解決的辦法是盡量不要定義name屬性，而是要把name變量分別定義在doGet()和doPost()方法內(nèi)。雖然使用synchronized(name){}語句塊可以解決問題，但是會造成線程的等待，不是很科學(xué)的辦法。

注意：多線程的并發(fā)的讀寫Servlet類屬性會導(dǎo)致數(shù)據(jù)不同步。但是如果只是并發(fā)地讀取屬性而不寫入，則不存在數(shù)據(jù)不同步的問題。因此Servlet里的只讀屬性最好定義為final類型的。

11、如果客戶端禁止 cookie 能實現(xiàn) session 還能用嗎？

Cookie 與 Session，一般認(rèn)為是兩個獨立的東西，Session采用的是在服務(wù)器端保持狀態(tài)的方案，而Cookie采用的是在客戶端保持狀態(tài)的方案。

但為什么禁用Cookie就不能得到Session呢？因為Session是用Session ID來確定當(dāng)前對話所對應(yīng)的服務(wù)器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當(dāng)于失去了Session ID，也就得不到Session了。

假定用戶關(guān)閉Cookie的情況下使用Session，其實現(xiàn)途徑有以下幾種：

手動通過URL傳值、隱藏表單傳遞Session ID。

用文件、數(shù)據(jù)庫等形式保存Session ID，在跨頁過程中手動調(diào)用。

九、TCP11種狀態(tài)

1、CLOSED狀態(tài)

初始狀態(tài)，表示TCP連接是“關(guān)閉的”或者“未打開的”。

2、LISTEN狀態(tài)

表示服務(wù)端的某個端口正處于監(jiān)聽狀態(tài)，正在等待客戶端連接的到來。

3、SYN_SENT狀態(tài)

當(dāng)客戶端發(fā)送SYN請求建立連接之后，客戶端處于SYN_SENT狀態(tài)，等待服務(wù)器發(fā)送SYN+ACK。

4、SYN_RCVD狀態(tài)

當(dāng)服務(wù)器收到來自客戶端的連接請求SYN之后，服務(wù)器處于SYN_RCVD狀態(tài)，在接收到SYN請求之后會向客戶端回復(fù)一個SYN+ACK的確認(rèn)報文。

5、ESTABLISED狀態(tài)

當(dāng)客戶端回復(fù)服務(wù)器一個ACK和服務(wù)器收到該ACK（TCP最后一次握手）之后，服務(wù)器和客戶端都處于該狀態(tài)，表示TCP連接已經(jīng)成功建立。

6、FIN_WAIT_1狀態(tài)

當(dāng)數(shù)據(jù)傳輸期間當(dāng)客戶端想斷開連接，向服務(wù)器發(fā)送了一個FIN之后，客戶端處于該狀態(tài)。

7、FIN_WAIT_2狀態(tài)

當(dāng)客戶端收到服務(wù)器發(fā)送的連接斷開確認(rèn)ACK之后，客戶端處于該狀態(tài)。

8、CLOSE_WAIT狀態(tài)

當(dāng)服務(wù)器發(fā)送連接斷開確認(rèn)ACK之后但是還沒有發(fā)送自己的FIN之前的這段時間，服務(wù)器處于該狀態(tài)。

9、TIME_WAIT狀態(tài)

當(dāng)客戶端收到了服務(wù)器發(fā)送的FIN并且發(fā)送了自己的ACK之后，客戶端處于該狀態(tài)。

10、LAST_ACK狀態(tài)

表示被動關(guān)閉的一方（比如服務(wù)器）在發(fā)送FIN之后，等待對方的ACK報文時，就處于該狀態(tài)。

11、CLOSING狀態(tài)

連接斷開期間，一般是客戶端發(fā)送一個FIN，然后服務(wù)器回復(fù)一個ACK，然后服務(wù)器發(fā)送完數(shù)據(jù)后再回復(fù)一個FIN，當(dāng)客戶端和服務(wù)器同時接受到FIN時，客戶端和服務(wù)器處于CLOSING狀態(tài)，也就是此時雙方都正在關(guān)閉同一個連接。

總結(jié)

以上是生活随笔為你收集整理的网络大全解答的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。