文章目錄

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

一、交換機工作原理

根據源MAC地址學習，根據目標MAC地址轉發
除源端口外的端口廣播未知數據幀

接收方回應
交換機實現單播通信

更新：老化時間300秒
交換機對應端口的MAC 地址發生變化時

二、路由

路由:跨越從源主機到目標主機的一個互聯網絡來轉發數據包的過程。

路由表：路由器根據路由表做路徑選擇

路由器的工作原理:根據路由表選擇最佳路徑,每個路由器都維護著一張路由表,這是路由器轉發數據包的關鍵,每條路由表記錄指明了到達某個子網或主機應從路由器的哪個物理端口發送,通過此端口可到達該路徑的下一個路由器的地址。

三、DHCP

基本原理:

第一步:客戶端通過廣播發送DHCP Discover報文尋找服務器端

第二步:服務器端通過單播發送DHCP Offer報文向客戶端提供IP地址等網絡信息

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

四、TCP和UDP的區別：

UDPTCP

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

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

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

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

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

運行在TCP協議上的協議：

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

運行在UDP協議上的協議：

• BOOTP（Boot Protocol，啟動協議），應用于無盤設備。
• NTP（Network Time Protocol，網絡時間協議），用于網絡同步。
• DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP地址。

運行在TCP和UDP協議上：

• DNS（Domain Name Service，域名服務），用于完成地址查找，郵件轉發等工作。

五、DNS

默認端口為53。

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

一、TCP是用來做區域傳送

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

六、ARP工作原理

每臺主機都會在自己的ARP緩沖區中建立一個 ARP列表，以表示IP地址和MAC地址的對應關系。

當源主機需要將一個數據包要發送到目的主機時，會首先檢查自己 ARP列表中是否存在該 IP地址對應的MAC地址。

如果有，就直接將數據包發送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。

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

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

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

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

如果源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

七、Ping和Traceroute

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

七、三次握手和四次揮手

三次握手的本質是確認通信雙方收發數據的能力

1.發送方向接收方發送SYN請求

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

3.發送方接收到接收方發來的SYN請求后，給出一個ACK確認。。

四次揮手的目的是關閉一個連接

1.發送方向接收方發送一個FIN請求

⒉接收方收到此請求后給出一個ACK確認（半關閉狀態）

3.接收方發送一個FIN請求給發送方

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

八、常見問題

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

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

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

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

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

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

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

4、如果已經建立了連接，但是客戶端突然出現故障了怎么辦？

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

5、什么是HTTP，HTTP 與 HTTPS 的區別

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

區別HTTPHTTPS

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

6、常用HTTP狀態碼

HTTP狀態碼表示客戶端HTTP請求的返回結果、標識服務器處理是否正常、表明請求出現的錯誤等。

狀態碼的類別：

類別原因短語

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

常用HTTP狀態碼：

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

200	OK，表示從客戶端發來的請求在服務器端被正確處理
204	No content，表示請求成功，但響應報文不含實體的主體部分
206	Partial Content，進行范圍請求成功

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

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

4XX客戶端錯誤

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

5XX服務器錯誤

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

6、GET和POST區別

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

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

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

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

GET和POST區別

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

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

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

Get執行效率卻比Post方法好。Get是form提交的默認方法。

GET產生一個TCP數據包；POST產生兩個TCP數據包。

對于GET方式的請求，瀏覽器會把http header和data一并發送出去，服務器響應200（返回數據）；

而對于POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。

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

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

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

8、什么是HTTP2

HTTP2 可以提高了網頁的性能。

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

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

9、Session、Cookie和Token的主要區別

HTTP協議本身是無狀態的。什么是無狀態呢，即服務器無法判斷用戶身份。

什么是cookie

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

什么是session

session是依賴Cookie實現的。session是服務器端對象

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

cookie與session區別

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

什么是Token

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

Token的定義：Token是服務端生成的一串字符串，以作客戶端進行請求的一個令牌，當第一次登錄后，服務器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數據即可，無需再次帶上用戶名和密碼。

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

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

session與token區別

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

10、Servlet是線程安全的嗎

Servlet不是線程安全的，多線程并發的讀寫會導致數據不同步的問題。

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

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

11、如果客戶端禁止 cookie 能實現 session 還能用嗎？

Cookie 與 Session，一般認為是兩個獨立的東西，Session采用的是在服務器端保持狀態的方案，而Cookie采用的是在客戶端保持狀態的方案。

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

假定用戶關閉Cookie的情況下使用Session，其實現途徑有以下幾種：

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

用文件、數據庫等形式保存Session ID，在跨頁過程中手動調用。

九、TCP11種狀態

1、CLOSED狀態

初始狀態，表示TCP連接是“關閉的”或者“未打開的”。

2、LISTEN狀態

表示服務端的某個端口正處于監聽狀態，正在等待客戶端連接的到來。

3、SYN_SENT狀態

當客戶端發送SYN請求建立連接之后，客戶端處于SYN_SENT狀態，等待服務器發送SYN+ACK。

4、SYN_RCVD狀態

當服務器收到來自客戶端的連接請求SYN之后，服務器處于SYN_RCVD狀態，在接收到SYN請求之后會向客戶端回復一個SYN+ACK的確認報文。

5、ESTABLISED狀態

當客戶端回復服務器一個ACK和服務器收到該ACK（TCP最后一次握手）之后，服務器和客戶端都處于該狀態，表示TCP連接已經成功建立。

6、FIN_WAIT_1狀態

當數據傳輸期間當客戶端想斷開連接，向服務器發送了一個FIN之后，客戶端處于該狀態。

7、FIN_WAIT_2狀態

當客戶端收到服務器發送的連接斷開確認ACK之后，客戶端處于該狀態。

8、CLOSE_WAIT狀態

當服務器發送連接斷開確認ACK之后但是還沒有發送自己的FIN之前的這段時間，服務器處于該狀態。

9、TIME_WAIT狀態

當客戶端收到了服務器發送的FIN并且發送了自己的ACK之后，客戶端處于該狀態。

10、LAST_ACK狀態

表示被動關閉的一方（比如服務器）在發送FIN之后，等待對方的ACK報文時，就處于該狀態。

11、CLOSING狀態

連接斷開期間，一般是客戶端發送一個FIN，然后服務器回復一個ACK，然后服務器發送完數據后再回復一個FIN，當客戶端和服務器同時接受到FIN時，客戶端和服務器處于CLOSING狀態，也就是此時雙方都正在關閉同一個連接。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。