网络大全解答
文章目錄
- 一、交換機工作原理
- 二、路由
- 三、DHCP
- 四、TCP和UDP的區(qū)別：
- 五、DNS
- 六、ARP工作原理
- 七、Ping和Traceroute
- 七、三次握手和四次揮手
- 三次握手的本質(zhì)是確認通信雙方收發(fā)數(shù)據(jù)的能力
- 四次揮手的目的是關(guān)閉一個連接
- 八、常見問題
- 1、為什么TCP連接的時候是3次？2次不可以嗎？
- 2、為什么TCP連接的時候是3次，關(guān)閉的時候卻是4次？
- 3、為什么客戶端發(fā)出第四次揮手的確認報文后要等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ù)源MAC地址學習，根據(jù)目標MAC地址轉(zhuǎn)發(fā)
除源端口外的端口廣播未知數(shù)據(jù)幀
接收方回應(yīng)
交換機實現(xiàn)單播通信
更新：老化時間300秒
交換機對應(yīng)端口的MAC 地址發(fā)生變化時
二、路由
路由:跨越從源主機到目標主機的一個互聯(lián)網(wǎng)絡(luò)來轉(zhuǎn)發(fā)數(shù)據(jù)包的過程。
路由表：路由器根據(jù)路由表做路徑選擇
路由器的工作原理:根據(jù)路由表選擇最佳路徑,每個路由器都維護著一張路由表,這是路由器轉(zhuǎn)發(fā)數(shù)據(jù)包的關(guān)鍵,每條路由表記錄指明了到達某個子網(wǎng)或主機應(yīng)從路由器的哪個物理端口發(fā)送,通過此端口可到達該路徑的下一個路由器的地址。
三、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ū)別：
| 是否連接 | 無連接 | 面向連接 |
| 是否可靠 | 不可靠傳輸，不使用流量控制和擁塞控制 | 可靠傳輸，使用流量控制和擁塞控制 |
| 連接對象個數(shù) | 支持一對一，一對多，多對一和多對多交互通信 | 只能是一對一通信 |
| 傳輸方式 | 面向報文 | 面向字節(jié)流 |
| 首部開銷 | 首部開銷小，僅8字節(jié) | 首部最小20字節(jié)，最大60字節(jié) |
| 場景 | 適用于實時應(yīng)用（IP電話、視頻會議、直播等） | 適用于要求可靠傳輸?shù)膽?yīng)用，例如文件傳輸 |
TCP:可靠的、面向連接的傳輸層協(xié)議。主要它有三次握手、四次斷開、窗口滑動、數(shù)據(jù)分段、數(shù)據(jù)重組、數(shù)據(jù)重傳機制保證數(shù)據(jù)的可靠性。。
UDP:不可靠的、面向無連接的傳輸層協(xié)議。它沒有什么機制保證數(shù)據(jù)可靠性,當數(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)主機配置協(xié)議），動態(tài)配置IP地址。
運行在TCP和UDP協(xié)議上：
- DNS（Domain Name Service，域名服務(wù)），用于完成地址查找，郵件轉(zhuǎn)發(fā)等工作。
五、DNS
默認端口為53。
DNS端口分為TCP和UDP。DNS協(xié)議運行在UDP協(xié)議之上
一、TCP是用來做區(qū)域傳送
二、UDP是用來做DNS解析的。
六、ARP工作原理
每臺主機都會在自己的ARP緩沖區(qū)中建立一個 ARP列表，以表示IP地址和MAC地址的對應(yīng)關(guān)系。
當源主機需要將一個數(shù)據(jù)包要發(fā)送到目的主機時，會首先檢查自己 ARP列表中是否存在該 IP地址對應(yīng)的MAC地址。
如果有，就直接將數(shù)據(jù)包發(fā)送到這個MAC地址；如果沒有，就向本地網(wǎng)段發(fā)起一個ARP請求的廣播包，查詢此目的主機對應(yīng)的MAC地址。
此ARP請求數(shù)據(jù)包里包括源主機的IP地址、硬件地址、以及目的主機的IP地址。網(wǎng)絡(luò)中所有的主機收到這個ARP請求后，會檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。
如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中。
如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機發(fā)送一個 ARP響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的MAC地址。
源主機收到這個ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。
如果源主機一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。
七、Ping和Traceroute
https://blog.csdn.net/tomatolee221/article/details/89531048
七、三次握手和四次揮手
三次握手的本質(zhì)是確認通信雙方收發(fā)數(shù)據(jù)的能力
1.發(fā)送方向接收方發(fā)送SYN請求
⒉接收方接收到此請求后會主動回復一個ACK，并且同時也發(fā)送一個SYN請求
3.發(fā)送方接收到接收方發(fā)來的SYN請求后，給出一個ACK確認。。
四次揮手的目的是關(guān)閉一個連接
1.發(fā)送方向接收方發(fā)送一個FIN請求
⒉接收方收到此請求后給出一個ACK確認（半關(guān)閉狀態(tài)）
3.接收方發(fā)送一個FIN請求給發(fā)送方
4.發(fā)送方收到接收方的FIN請求后，回復一個ACK。
八、常見問題
1、為什么TCP連接的時候是3次？2次不可以嗎？
因為需要考慮連接時丟包的問題，如果只握手2次，第二次握手時如果服務(wù)端發(fā)給客戶端的確認報文段丟失，此時服務(wù)端已經(jīng)準備好了收發(fā)數(shù)(可以理解服務(wù)端已經(jīng)連接成功)據(jù)，而客戶端一直沒收到服務(wù)端的確認報文，所以客戶端就不知道服務(wù)端是否已經(jīng)準備好了(可以理解為客戶端未連接成功)，這種情況下客戶端不會給服務(wù)端發(fā)數(shù)據(jù)，也會忽略服務(wù)端發(fā)過來的數(shù)據(jù)。
如果是三次握手，即便發(fā)生丟包也不會有問題，比如如果第三次握手客戶端發(fā)的確認ack報文丟失，服務(wù)端在一段時間內(nèi)沒有收到確認ack報文的話就會重新進行第二次握手，也就是服務(wù)端會重發(fā)SYN報文段，客戶端收到重發(fā)的報文段后會再次給服務(wù)端發(fā)送確認ack報文。
2、為什么TCP連接的時候是3次，關(guān)閉的時候卻是4次？
因為只有在客戶端和服務(wù)端都沒有數(shù)據(jù)要發(fā)送的時候才能斷開TCP。而客戶端發(fā)出FIN報文時只能保證客戶端沒有數(shù)據(jù)發(fā)了，服務(wù)端還有沒有數(shù)據(jù)發(fā)客戶端是不知道的。而服務(wù)端收到客戶端的FIN報文后只能先回復客戶端一個確認報文來告訴客戶端我服務(wù)端已經(jīng)收到你的FIN報文了，但我服務(wù)端還有一些數(shù)據(jù)沒發(fā)完，等這些數(shù)據(jù)發(fā)完了服務(wù)端才能給客戶端發(fā)FIN報文(所以不能一次性將確認報文和FIN報文發(fā)給客戶端，就是這里多出來了一次)。
3、為什么客戶端發(fā)出第四次揮手的確認報文后要等2MSL的時間才能釋放TCP連接？
這里同樣是要考慮丟包的問題，如果第四次揮手的報文丟失，服務(wù)端沒收到確認ack報文就會重發(fā)第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這么長時間來確認服務(wù)端確實已經(jīng)收到了。
4、如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
TCP設(shè)有一個保活計時器，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認為客戶端出了故障，接著就關(guān)閉連接。
5、什么是HTTP，HTTP 與 HTTPS 的區(qū)別
HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范
| 協(xié)議 | 運行在 TCP 之上，明文傳輸，客戶端與服務(wù)器端都無法驗證對方的身份 | 身披 SSL( Secure Socket Layer )外殼的 HTTP，運行于 SSL 上，SSL 運行于 TCP 之上， 是添加了加密和認證機制的 HTTP。 |
| 端口 | 80 | 443 |
| 資源消耗 | 較少 | 由于加解密處理，會消耗更多的 CPU 和內(nèi)存資源 |
| 開銷 | 無需證書 | 需要證書，而證書一般需要向認證機構(gòu)購買 |
| 加密機制 | 無 | 共享密鑰加密和公開密鑰加密并用的混合加密機制 |
| 安全性 | 弱 | 由于加密機制，安全性強 |
6、常用HTTP狀態(tài)碼
HTTP狀態(tài)碼表示客戶端HTTP請求的返回結(jié)果、標識服務(wù)器處理是否正常、表明請求出現(xiàn)的錯誤等。
狀態(tài)碼的類別：
| 1XX | Informational（信息性狀態(tài)碼） 接受的請求正在處理 |
| 2XX | Success（成功狀態(tài)碼） 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態(tài)碼） 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態(tài)碼） 服務(wù)器無法處理請求 |
| 5XX | Server Error（服務(wù)器錯誤狀態(tài)碼） 服務(wù)器處理請求出錯 |
常用HTTP狀態(tài)碼：
| 200 | OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理 |
| 204 | No content，表示請求成功，但響應(yīng)報文不含實體的主體部分 |
| 206 | Partial Content，進行范圍請求成功 |
| 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ā)出請求 |
| 400 | bad request，請求報文存在語法錯誤 |
| 401 | unauthorized，表示發(fā)送的請求需要有通過 HTTP 認證的認證信息 |
| 403 | forbidden，表示對請求資源的訪問被服務(wù)器拒絕，可在實體主體部分返回原因描述 |
| 404 | not found，表示在服務(wù)器上沒有找到請求的資源 |
| 500 | internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤 |
| 501 | Not Implemented，表示服務(wù)器不支持當前請求所需要的某個功能 |
| 503 | service unavailable，表明服務(wù)器暫時處于超負載或正在停機維護，無法處理請求 |
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ù)器進行交互的不同方法，基本方法有4種，分別是GET，POST，PUT，DELETE。這四種方法可以理解為，對服務(wù)器資源的查，改，增，刪。
- GET：從服務(wù)器上獲取數(shù)據(jù)，也就是所謂的查，僅僅是獲取服務(wù)器資源，不進行修改。
- 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長度進行限制，目的是為了保證服務(wù)器和瀏覽器能夠正常運行，防止有人惡意發(fā)送請求。Post請求則沒有大小限制。
Get限制Form表單的數(shù)據(jù)集的值必須為ASCII字符；而Post支持整個ISO10646字符集。
Get執(zhí)行效率卻比Post方法好。Get是form提交的默認方法。
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ā)送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息后，使用自己的私鑰進行解密。
由于非對稱加密的方式不需要發(fā)送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，非常的慢
8、什么是HTTP2
HTTP2 可以提高了網(wǎng)頁的性能。
在 HTTP1 中瀏覽器限制了同一個域名下的請求數(shù)量（Chrome 下一般是六個），當在請求很多資源的時候，由于隊頭阻塞當瀏覽器達到最大請求數(shù)量時，剩余的資源需等待當前的六個請求完成后才能發(fā)起請求。
HTTP2 中引入了多路復用的技術(shù)，這個技術(shù)可以只通過一個 TCP 連接就可以傳輸所有的請求數(shù)據(jù)。多路復用可以繞過瀏覽器限制同一個域名下的請求數(shù)量的問題，進而提高了網(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保存起來。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認用戶身份。
什么是session
session是依賴Cookie實現(xiàn)的。session是服務(wù)器端對象
session 是瀏覽器和服務(wù)器會話過程中，服務(wù)器分配的一塊儲存空間。服務(wù)器默認為瀏覽器在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ù)器上，當訪問增多，占用服務(wù)器性能，考慮到服務(wù)器性能方面，應(yīng)當使用cookie。
什么是Token
Token的引入：Token是在客戶端頻繁向服務(wù)端請求數(shù)據(jù)，服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進行對比，判斷用戶名和密碼正確與否，并作出相應(yīng)提示，在這樣的背景下，Token便應(yīng)運而生。
Token的定義：Token是服務(wù)端生成的一串字符串，以作客戶端進行請求的一個令牌，當?shù)谝淮蔚卿浐?#xff0c;服務(wù)器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。
使用Token的目的：Token的目的是為了減輕服務(wù)器的壓力，減少頻繁的查詢數(shù)據(jù)庫，使服務(wù)器更加健壯。
Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請求認證，服務(wù)端認證成功，那么在服務(wù)端會返回 Token 給前端。前端可以在每次請求的時候帶上 Token 證明自己的合法地位
session與token區(qū)別
- session機制存在服務(wù)器壓力增大，CSRF跨站偽造請求攻擊，擴展性不強等問題；
- session存儲在服務(wù)器端，token存儲在客戶端
- token提供認證和授權(quán)功能，作為身份認證，token安全性比session好；
- session這種會話存儲方式方式只適用于客戶端代碼和服務(wù)端代碼運行在同一臺服務(wù)器上，token適用于項目級的前后端分離（前后端代碼運行在不同的服務(wù)器下）
10、Servlet是線程安全的嗎
Servlet不是線程安全的，多線程并發(fā)的讀寫會導致數(shù)據(jù)不同步的問題。
解決的辦法是盡量不要定義name屬性，而是要把name變量分別定義在doGet()和doPost()方法內(nèi)。雖然使用synchronized(name){}語句塊可以解決問題，但是會造成線程的等待，不是很科學的辦法。
注意：多線程的并發(fā)的讀寫Servlet類屬性會導致數(shù)據(jù)不同步。但是如果只是并發(fā)地讀取屬性而不寫入，則不存在數(shù)據(jù)不同步的問題。因此Servlet里的只讀屬性最好定義為final類型的。
11、如果客戶端禁止 cookie 能實現(xiàn) session 還能用嗎？
Cookie 與 Session，一般認為是兩個獨立的東西，Session采用的是在服務(wù)器端保持狀態(tài)的方案，而Cookie采用的是在客戶端保持狀態(tài)的方案。
但為什么禁用Cookie就不能得到Session呢？因為Session是用Session ID來確定當前對話所對應(yīng)的服務(wù)器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當于失去了Session ID，也就得不到Session了。
假定用戶關(guān)閉Cookie的情況下使用Session，其實現(xiàn)途徑有以下幾種：
九、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)
當客戶端發(fā)送SYN請求建立連接之后，客戶端處于SYN_SENT狀態(tài)，等待服務(wù)器發(fā)送SYN+ACK。
4、SYN_RCVD狀態(tài)
當服務(wù)器收到來自客戶端的連接請求SYN之后，服務(wù)器處于SYN_RCVD狀態(tài)，在接收到SYN請求之后會向客戶端回復一個SYN+ACK的確認報文。
5、ESTABLISED狀態(tài)
當客戶端回復服務(wù)器一個ACK和服務(wù)器收到該ACK（TCP最后一次握手）之后，服務(wù)器和客戶端都處于該狀態(tài)，表示TCP連接已經(jīng)成功建立。
6、FIN_WAIT_1狀態(tài)
當數(shù)據(jù)傳輸期間當客戶端想斷開連接，向服務(wù)器發(fā)送了一個FIN之后，客戶端處于該狀態(tài)。
7、FIN_WAIT_2狀態(tài)
當客戶端收到服務(wù)器發(fā)送的連接斷開確認ACK之后，客戶端處于該狀態(tài)。
8、CLOSE_WAIT狀態(tài)
當服務(wù)器發(fā)送連接斷開確認ACK之后但是還沒有發(fā)送自己的FIN之前的這段時間，服務(wù)器處于該狀態(tài)。
9、TIME_WAIT狀態(tài)
當客戶端收到了服務(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ù)器回復一個ACK，然后服務(wù)器發(fā)送完數(shù)據(jù)后再回復一個FIN，當客戶端和服務(wù)器同時接受到FIN時，客戶端和服務(wù)器處于CLOSING狀態(tài)，也就是此時雙方都正在關(guān)閉同一個連接。
總結(jié)
- 上一篇： Linux 查询 OS、CPU、内存、硬
- 下一篇： Shell概述