1. TCP/IP

1.1 傳統的OSI(Open System Interconnection)參考模型是7層：應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層。而TCP/IP是5層參考模型：應用層(HTTP、FTP等協議)、傳輸層(TCP、UDP協議)、網絡層(IP協議)、數據鏈路層(ARP協議，IEEE802.3以太網協議)和物理層

1.2 TCP和UDP的區別：①TCP面向連接，傳輸數據需要先建立連接，UDP是不需要連接的；②TCP提供可靠的服務，保證數據無差錯、不丟失，UDP則不保證可靠性；③TCP傳輸效率低，UDP傳輸效率高。

1.3 TCP怎么實現可靠的連接：①三次握手和四次揮手；②校驗和、ACK應答、丟包重傳、流量控制和擁塞控制等機制。

1.4 三次握手和四次揮手：①客戶端發送同步序列號K(字符表示是SYN K)；②服務端接受到該序列號，響應客戶端序列號K+1的同時發送一個同步序列號M(ACK K+1, SYN M)；③客戶端接收到響應序列號K+1，同時響應服務端序列號M+1(ACK M+1)。為什么是三次呢？因為TCP是雙向通道，要確保接受和發送都沒有問題，只有當每次發送的序列號，得到響應才證明收發都沒有問題，下面借用潛行前行公眾號的一張圖。那么揮手為什么是四次呢？因為客戶端要關閉連接時，服務端的數據可能還沒傳輸完成，所以先響應客戶端，等到真正傳輸完成再發送指令FIN。

? ? ?

? ? ? ? ??

1.5 丟包的超時重傳：①由于網絡問題，在客戶端發送和接收過程中存在丟包情況；②發送時丟包，那么客戶端在規定時間內就收不到服務端的響應，規定時間后會重傳。③發送是成功的，但是服務端的響應沒被客戶端收到，規定時間后客戶端仍會重傳，但是服務端通過序列號(通過序列號可知目前接收的數據，以及下一次要接收的數據)發現該數據已接收，那么直接丟棄，然后繼續響應上次的序列號。④如果在重傳數據后，網絡恢復，之前丟包的數據、響應送達客戶端或服務端，這種情況怎么處理？這時通過序列號就可以很好的知道數據或者響應正不正確了，從而決定是丟棄還是處理。

1.6 流量控制：接收方將自己緩沖區剩余容量大小放入TCP的“窗口大小”字段(滑動窗口)，通過ACK報文響應給發送端，設定發送端發送數據的大小。

1.7 擁塞控制

1.7.1 慢啟動和擁塞避免：①慢啟動：發送端會維護一個擁塞窗口(縮寫為cwnd)，初始可發送的報文段是1，然后每成功傳輸一次數據，擁塞窗口大小翻倍(指數增長)；②擁塞避免：當慢啟動的cwnd大小達到ssthresh(擁塞避免閾值)后，為了避免擁塞，每成功傳輸一次數據，擁塞窗口加1(線性增長)。③每次遇到網絡擁塞(貌似沒有具體的判斷依據，通過網絡負載和吞吐量決定)，就會將擁塞窗口大小設為1，同時將ssthresh設為網絡擁塞時擁塞窗口大小的一半。還是借用潛行潛行公眾號的一張圖，如下。

1.7.2 快重傳和快恢復：①快重傳：由于某個數據段的丟包，發送方在等待響應時發送的其它報文，接收方都只會響應丟包前的那個響應序列號，發送方只要連續收到3個重復的響應序列號，立即從響應序列號后的數據開始重傳，避免了在等待丟包數據的響應時重復發送沒用的數據，避免網絡擁塞。②快恢復：數據包的丟失可能是因為網絡阻塞導致，所以這個時候應該重新進行慢啟動和擁塞避免過程；但有可能又不是網絡阻塞導致，所以不走慢啟動，直接走擁塞避免過程，將ssthresh和cwnd都調整為當前cwnd的一半，然后cwnd按照擁塞避免原則線性增長。

1.8 擁塞窗口和滑動窗口的區別：相同點都是控制發送數據的大小；不同點是擁塞窗口根據網絡情況限制數據的傳輸，而滑動窗口根據接收方的緩沖區大小限制數據的傳輸。

1.9 粘包和拆包問題：程序需要發送的數據大小和TCP單次所能發送的報文長度(Maximum Segment Size, MSS)是不一樣的。當需要發送的數據大于MSS，需要將數據拆分多次發送，稱之為拆包；當需要發送的數據小于MSS，會考慮將多個數據一起發送，稱之為粘包。解決：①使用特殊字符作為數據的結尾或開頭；

1.10 TCP四種計時器：①重傳計時器：用于在規定時間(通常是60秒)內沒有收到響應報文，進行數據重傳。②堅持計時器：當流量控制的滑動窗口大小為零的時候啟動，當時間到了(通常是60秒)就發送一個報文進行探測。③保活計時器：避免TCP連接沒有關閉而長期空閑，每次收到數據，就將計時器復位，默認設置為2小時。④時間等待計時器：連接關閉時，并不馬上就關閉，因為接收方可能還在傳輸數據，時間大小一般是30秒到2分鐘。

1.11 四次揮手時，客戶端收到服務端的FIN后，需要等待2個MSL(Max Segment LifeTime)再進入Closed狀態，為什么？①保證客戶端發送的ACK報文能夠到達服務端，有這個2MSL時間，那么當服務端沒有收到ACK報文時重傳FIN+ACK報文，客戶端還可以再發送ACK報文；②可以讓本連接的報文段從網絡中清空。

1.12 TCP四次揮手時，服務端主動斷開和客戶端主動斷開的區別。因為主動斷開的一方有2MSL時間的TIME_WAIT狀態，則會存在一段時間有較多連接處于TIME_WAIT狀態，Windows默認是4分鐘，有損性能。解決：進行相關參數的配置：如更改MSL的時間，開啟TIME_WAIT狀態的TCP連接重用，開啟TIME_WAIT狀態的TCP連接回收。MSL時間是不是也可以處于某個范圍。

1.13?TCP自身可以分段和重組(最大分段大小，MSS)；UDP不會分段，由網絡層分片和重組（最大傳輸單元，MTU）

2. JavaWeb內容及HTTP協議

2.1 在瀏覽器地址欄輸入一個網址，經歷了哪些步驟？①域名解析(瀏覽器DNS緩存--》操作系統自身DNS緩存--》讀取host文件--》本地域名服務器...根域名服務器)；②進行TCP3次握手建立連接；③瀏覽器發送http請求；④服務器響應http請求；⑤瀏覽器解析響應內容并渲染。

2.2 HTTP(HyperText Transfer Protocol)協議：超文本傳輸協議，瀏覽器和服務器之間傳輸數據的一種協議。

2.3 HTTP協議的無狀態：每一次HTTP請求都是獨立的，之間沒有聯系。這就會出現上一次賬戶登錄，但下一次進行一些賬戶操作時，不知道是對哪個賬戶操作的情況。所以通過cookie和session機制來保持“狀態”。

2.4 cookie：① 服務器通知客戶端保存鍵值對數據的一種技術，客戶端有cookie后每次向服務器發起請求都會帶上cookie；② cookie的生命周期控制：正數表示指定秒數后過期；負數表示瀏覽器關閉cookie就過期，默認設置；零表示馬上刪除cookie。③cookie的有效范圍：上級目錄設置的cookie，下級目錄可以獲取；下級目錄設置的cookie，上級目錄獲取不到。

2.5 session：①維護客戶端和服務器之間關聯的一種技術，在服務器端保存，底層是cookie技術，依賴于名為JSESSIONID的cookie；②剛開始客戶端發起請求沒有數據，然后服務器收到請求如果要創建session，會先判斷有沒有，沒有就創建，并且通過set-cookie命令告訴客戶端創建cookie對象，之后客戶端發請求都會帶上該cookie；服務端再通過該cookie的數據可以找到之前創建好的session對象。

2.6?常見狀態碼：200：請求成功；301：永久重定向，并且之后訪問會直接使用得到的永久重定向地址，常見的是域名跳轉；302：臨時重定向；303：也是臨時重定向，但以get方式發起重定向；304：發起的請求使用緩存的資源；307：臨時重定向，和303一樣，但是不會把post重定向請求改為get方式；400：客戶端發起的請求有誤；403：資源訪問被拒絕；404：資源找不到；500：服務器內部發生錯誤。

2.7 304：首先判斷資源是否過期，如果未過期，不會發起請求，直接使用瀏覽器緩存的資源，如果過期，那么向服務器發起請求。如果服務器資源文件有改動，那么返回新的資源文件以及200狀態碼；如果未改動，那么返回304狀態碼，然后瀏覽器使用之前緩存的資源文件。緩存過期有兩種方式，cache-control和expires兩種，cache-control優先級更高。資源文件改動判斷：客戶端第一次請求資源文件后，服務器端的響應頭會帶有last-modified字段；之后資源過期，客戶端再發起請求，在請求頭中會帶有if-modified-since字段(就是第一次的last-modified字段內容)，然后服務端會拿這個值和資源文件的最后修改時間對比，如果相等就返回304，讓客戶端使用過期的數據；如果不相等，重新響應新的資源文件并返回狀態碼200。

2.8?HTTP請求報文：①三部分：請求行、請求頭和請求體，請求頭和請求體之間有空行；②請求行：請求方式(GET還是POST等)，請求資源路徑，請求的協議和版本號。?

2.9?HTTP響應報文：①三部分：響應行、響應頭和響應體，響應頭和響應體之間有空行；②響應行：響應的協議和版本號，響應狀態碼，響應狀態描述符。

2.10?HTTP協議的1.0和1.1區別：1.1版本引入了長連接的概念，避免了1.0版本單個請求結束就關閉連接的弊端(建立連接和關閉連接耗費資源)，但是時間長了之后，服務端會有較多連接。

2.11 HTTPS和HTTP的區別：HTTP是明文傳輸，HTTPS則在HTTP基礎上加了SSL/TLS（Secure Socket Layer和Transport Layer Security），因此具備內容加密、身份認證、數據完整性(確保數據不被改變)的功能。

2.12 內容加密：分為非對稱加密和對稱加密。對稱加密：加密和解密使用相同的算法，不夠安全；非對稱加密：加密和解密使用不同算法，得不到解密的私鑰，就算有加密的公鑰也解析不了非法攔截的用戶數據。

2.13 身份認證：如果非法用戶將自己私鑰計算的簽名和公鑰發給客戶，那么客戶端驗證會通過。為了避免這種情況，數字證書需要經由CA第三方機構統一管理，如果不被CA認證通過，那么認證失敗。

2.14?數據完整性：發送者對響應報文進行hash運算，得到Digest，然后再用私鑰加密，得到數字簽名，最終接收者通過對比公鑰解析數字簽名得到的Digest和數據hash運算的Digest，從而確定數據是否被修改過。

2.15 HTTP1.1和HTTP2.0的區別：HTTP1.1雖然已經實現了管線化(不等待響應，可發送下一個請求)，但是客戶端還是按照請求的發送順序接收響應。會出現線頭阻塞情況(某個請求耗時會阻塞其它請求)。HTTP2.0通過多路復用，可以避免線頭阻塞情況。

3. FTP協議

3.1 FTP僅基于TCP，不支持UDP。

3.2 FTP使用2個端口進行數據和指令的傳輸，然后分兩種工作方式——PORT和PASV模式。

3.3 PORT模式(服務端去連接客戶端)：①客戶端通過端口 N 先和服務端的命令端口 21 建立TCP連接；②然后客戶端發送命令 PORT N+1 到服務端；③服務端先響應 ACK，接著服務端從數據端口 20 發起一個到客戶端?N+1端口的連接；④最后客戶端從 N+1 端口響應一個 ACK。

3.4 PASV模式(客戶端去連接服務端)：①客戶端通過端口 M 和服務端的命令端口21建立TCP連接；②然后客戶端發送命令 PASV 到服務端；③服務端返回 PORT X；④客戶端通過 M+1 端口向服務端的數據端口 X 發起連接，然后服務端向客戶端返回一個 ACK。

3.5 客戶端沒有公網IP，所以一般客戶端使用PASV方式，才能連接FTP服務器。

總結

以上是生活随笔為你收集整理的TCP/IP面试常问合集，JavaWeb内容及HTTP协议的全部內容，希望文章能夠幫你解決所遇到的問題。

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