1. TCP/IP

1.1 傳統(tǒng)的OSI(Open System Interconnection)參考模型是7層：應(yīng)用層、表示層、會(huì)話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。而TCP/IP是5層參考模型：應(yīng)用層(HTTP、FTP等協(xié)議)、傳輸層(TCP、UDP協(xié)議)、網(wǎng)絡(luò)層(IP協(xié)議)、數(shù)據(jù)鏈路層(ARP協(xié)議，IEEE802.3以太網(wǎng)協(xié)議)和物理層

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

1.3 TCP怎么實(shí)現(xiàn)可靠的連接：①三次握手和四次揮手；②校驗(yàn)和、ACK應(yīng)答、丟包重傳、流量控制和擁塞控制等機(jī)制。

1.4 三次握手和四次揮手：①客戶端發(fā)送同步序列號(hào)K(字符表示是SYN K)；②服務(wù)端接受到該序列號(hào)，響應(yīng)客戶端序列號(hào)K+1的同時(shí)發(fā)送一個(gè)同步序列號(hào)M(ACK K+1, SYN M)；③客戶端接收到響應(yīng)序列號(hào)K+1，同時(shí)響應(yīng)服務(wù)端序列號(hào)M+1(ACK M+1)。為什么是三次呢？因?yàn)門CP是雙向通道，要確保接受和發(fā)送都沒(méi)有問(wèn)題，只有當(dāng)每次發(fā)送的序列號(hào)，得到響應(yīng)才證明收發(fā)都沒(méi)有問(wèn)題，下面借用潛行前行公眾號(hào)的一張圖。那么揮手為什么是四次呢？因?yàn)榭蛻舳艘P(guān)閉連接時(shí)，服務(wù)端的數(shù)據(jù)可能還沒(méi)傳輸完成，所以先響應(yīng)客戶端，等到真正傳輸完成再發(fā)送指令FIN。

? ? ?

? ? ? ? ??

1.5 丟包的超時(shí)重傳：①由于網(wǎng)絡(luò)問(wèn)題，在客戶端發(fā)送和接收過(guò)程中存在丟包情況；②發(fā)送時(shí)丟包，那么客戶端在規(guī)定時(shí)間內(nèi)就收不到服務(wù)端的響應(yīng)，規(guī)定時(shí)間后會(huì)重傳。③發(fā)送是成功的，但是服務(wù)端的響應(yīng)沒(méi)被客戶端收到，規(guī)定時(shí)間后客戶端仍會(huì)重傳，但是服務(wù)端通過(guò)序列號(hào)(通過(guò)序列號(hào)可知目前接收的數(shù)據(jù)，以及下一次要接收的數(shù)據(jù))發(fā)現(xiàn)該數(shù)據(jù)已接收，那么直接丟棄，然后繼續(xù)響應(yīng)上次的序列號(hào)。④如果在重傳數(shù)據(jù)后，網(wǎng)絡(luò)恢復(fù)，之前丟包的數(shù)據(jù)、響應(yīng)送達(dá)客戶端或服務(wù)端，這種情況怎么處理？這時(shí)通過(guò)序列號(hào)就可以很好的知道數(shù)據(jù)或者響應(yīng)正不正確了，從而決定是丟棄還是處理。

1.6 流量控制：接收方將自己緩沖區(qū)剩余容量大小放入TCP的“窗口大小”字段(滑動(dòng)窗口)，通過(guò)ACK報(bào)文響應(yīng)給發(fā)送端，設(shè)定發(fā)送端發(fā)送數(shù)據(jù)的大小。

1.7 擁塞控制

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

1.7.2 快重傳和快恢復(fù)：①快重傳：由于某個(gè)數(shù)據(jù)段的丟包，發(fā)送方在等待響應(yīng)時(shí)發(fā)送的其它報(bào)文，接收方都只會(huì)響應(yīng)丟包前的那個(gè)響應(yīng)序列號(hào)，發(fā)送方只要連續(xù)收到3個(gè)重復(fù)的響應(yīng)序列號(hào)，立即從響應(yīng)序列號(hào)后的數(shù)據(jù)開始重傳，避免了在等待丟包數(shù)據(jù)的響應(yīng)時(shí)重復(fù)發(fā)送沒(méi)用的數(shù)據(jù)，避免網(wǎng)絡(luò)擁塞。②快恢復(fù)：數(shù)據(jù)包的丟失可能是因?yàn)榫W(wǎng)絡(luò)阻塞導(dǎo)致，所以這個(gè)時(shí)候應(yīng)該重新進(jìn)行慢啟動(dòng)和擁塞避免過(guò)程；但有可能又不是網(wǎng)絡(luò)阻塞導(dǎo)致，所以不走慢啟動(dòng)，直接走擁塞避免過(guò)程，將ssthresh和cwnd都調(diào)整為當(dāng)前cwnd的一半，然后cwnd按照擁塞避免原則線性增長(zhǎng)。

1.8 擁塞窗口和滑動(dòng)窗口的區(qū)別：相同點(diǎn)都是控制發(fā)送數(shù)據(jù)的大小；不同點(diǎn)是擁塞窗口根據(jù)網(wǎng)絡(luò)情況限制數(shù)據(jù)的傳輸，而滑動(dòng)窗口根據(jù)接收方的緩沖區(qū)大小限制數(shù)據(jù)的傳輸。

1.9 粘包和拆包問(wèn)題：程序需要發(fā)送的數(shù)據(jù)大小和TCP單次所能發(fā)送的報(bào)文長(zhǎng)度(Maximum Segment Size, MSS)是不一樣的。當(dāng)需要發(fā)送的數(shù)據(jù)大于MSS，需要將數(shù)據(jù)拆分多次發(fā)送，稱之為拆包；當(dāng)需要發(fā)送的數(shù)據(jù)小于MSS，會(huì)考慮將多個(gè)數(shù)據(jù)一起發(fā)送，稱之為粘包。解決：①使用特殊字符作為數(shù)據(jù)的結(jié)尾或開頭；

1.10 TCP四種計(jì)時(shí)器：①重傳計(jì)時(shí)器：用于在規(guī)定時(shí)間(通常是60秒)內(nèi)沒(méi)有收到響應(yīng)報(bào)文，進(jìn)行數(shù)據(jù)重傳。②堅(jiān)持計(jì)時(shí)器：當(dāng)流量控制的滑動(dòng)窗口大小為零的時(shí)候啟動(dòng)，當(dāng)時(shí)間到了(通常是60秒)就發(fā)送一個(gè)報(bào)文進(jìn)行探測(cè)。③保活計(jì)時(shí)器：避免TCP連接沒(méi)有關(guān)閉而長(zhǎng)期空閑，每次收到數(shù)據(jù)，就將計(jì)時(shí)器復(fù)位，默認(rèn)設(shè)置為2小時(shí)。④時(shí)間等待計(jì)時(shí)器：連接關(guān)閉時(shí)，并不馬上就關(guān)閉，因?yàn)榻邮辗娇赡苓€在傳輸數(shù)據(jù)，時(shí)間大小一般是30秒到2分鐘。

1.11 四次揮手時(shí)，客戶端收到服務(wù)端的FIN后，需要等待2個(gè)MSL(Max Segment LifeTime)再進(jìn)入Closed狀態(tài)，為什么？①保證客戶端發(fā)送的ACK報(bào)文能夠到達(dá)服務(wù)端，有這個(gè)2MSL時(shí)間，那么當(dāng)服務(wù)端沒(méi)有收到ACK報(bào)文時(shí)重傳FIN+ACK報(bào)文，客戶端還可以再發(fā)送ACK報(bào)文；②可以讓本連接的報(bào)文段從網(wǎng)絡(luò)中清空。

1.12 TCP四次揮手時(shí)，服務(wù)端主動(dòng)斷開和客戶端主動(dòng)斷開的區(qū)別。因?yàn)橹鲃?dòng)斷開的一方有2MSL時(shí)間的TIME_WAIT狀態(tài)，則會(huì)存在一段時(shí)間有較多連接處于TIME_WAIT狀態(tài)，Windows默認(rèn)是4分鐘，有損性能。解決：進(jìn)行相關(guān)參數(shù)的配置：如更改MSL的時(shí)間，開啟TIME_WAIT狀態(tài)的TCP連接重用，開啟TIME_WAIT狀態(tài)的TCP連接回收。MSL時(shí)間是不是也可以處于某個(gè)范圍。

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

2. JavaWeb內(nèi)容及HTTP協(xié)議

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

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

2.3 HTTP協(xié)議的無(wú)狀態(tài)：每一次HTTP請(qǐng)求都是獨(dú)立的，之間沒(méi)有聯(lián)系。這就會(huì)出現(xiàn)上一次賬戶登錄，但下一次進(jìn)行一些賬戶操作時(shí)，不知道是對(duì)哪個(gè)賬戶操作的情況。所以通過(guò)cookie和session機(jī)制來(lái)保持“狀態(tài)”。

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

2.5 session：①維護(hù)客戶端和服務(wù)器之間關(guān)聯(lián)的一種技術(shù)，在服務(wù)器端保存，底層是cookie技術(shù)，依賴于名為JSESSIONID的cookie；②剛開始客戶端發(fā)起請(qǐng)求沒(méi)有數(shù)據(jù)，然后服務(wù)器收到請(qǐng)求如果要?jiǎng)?chuàng)建session，會(huì)先判斷有沒(méi)有，沒(méi)有就創(chuàng)建，并且通過(guò)set-cookie命令告訴客戶端創(chuàng)建cookie對(duì)象，之后客戶端發(fā)請(qǐng)求都會(huì)帶上該cookie；服務(wù)端再通過(guò)該cookie的數(shù)據(jù)可以找到之前創(chuàng)建好的session對(duì)象。

2.6?常見(jiàn)狀態(tài)碼：200：請(qǐng)求成功；301：永久重定向，并且之后訪問(wèn)會(huì)直接使用得到的永久重定向地址，常見(jiàn)的是域名跳轉(zhuǎn)；302：臨時(shí)重定向；303：也是臨時(shí)重定向，但以get方式發(fā)起重定向；304：發(fā)起的請(qǐng)求使用緩存的資源；307：臨時(shí)重定向，和303一樣，但是不會(huì)把post重定向請(qǐng)求改為get方式；400：客戶端發(fā)起的請(qǐng)求有誤；403：資源訪問(wèn)被拒絕；404：資源找不到；500：服務(wù)器內(nèi)部發(fā)生錯(cuò)誤。

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

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

2.9?HTTP響應(yīng)報(bào)文：①三部分：響應(yīng)行、響應(yīng)頭和響應(yīng)體，響應(yīng)頭和響應(yīng)體之間有空行；②響應(yīng)行：響應(yīng)的協(xié)議和版本號(hào)，響應(yīng)狀態(tài)碼，響應(yīng)狀態(tài)描述符。

2.10?HTTP協(xié)議的1.0和1.1區(qū)別：1.1版本引入了長(zhǎng)連接的概念，避免了1.0版本單個(gè)請(qǐng)求結(jié)束就關(guān)閉連接的弊端(建立連接和關(guān)閉連接耗費(fèi)資源)，但是時(shí)間長(zhǎng)了之后，服務(wù)端會(huì)有較多連接。

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

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

2.13 身份認(rèn)證：如果非法用戶將自己私鑰計(jì)算的簽名和公鑰發(fā)給客戶，那么客戶端驗(yàn)證會(huì)通過(guò)。為了避免這種情況，數(shù)字證書需要經(jīng)由CA第三方機(jī)構(gòu)統(tǒng)一管理，如果不被CA認(rèn)證通過(guò)，那么認(rèn)證失敗。

2.14?數(shù)據(jù)完整性：發(fā)送者對(duì)響應(yīng)報(bào)文進(jìn)行hash運(yùn)算，得到Digest，然后再用私鑰加密，得到數(shù)字簽名，最終接收者通過(guò)對(duì)比公鑰解析數(shù)字簽名得到的Digest和數(shù)據(jù)hash運(yùn)算的Digest，從而確定數(shù)據(jù)是否被修改過(guò)。

2.15 HTTP1.1和HTTP2.0的區(qū)別：HTTP1.1雖然已經(jīng)實(shí)現(xiàn)了管線化(不等待響應(yīng)，可發(fā)送下一個(gè)請(qǐng)求)，但是客戶端還是按照請(qǐng)求的發(fā)送順序接收響應(yīng)。會(huì)出現(xiàn)線頭阻塞情況(某個(gè)請(qǐng)求耗時(shí)會(huì)阻塞其它請(qǐng)求)。HTTP2.0通過(guò)多路復(fù)用，可以避免線頭阻塞情況。

3. FTP協(xié)議

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

3.2 FTP使用2個(gè)端口進(jìn)行數(shù)據(jù)和指令的傳輸，然后分兩種工作方式——PORT和PASV模式。

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

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

3.5 客戶端沒(méi)有公網(wǎng)IP，所以一般客戶端使用PASV方式，才能連接FTP服務(wù)器。

總結(jié)

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

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