网络大全解答
文章目錄
- 一、交換機工作原理
- 二、路由
- 三、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概述