Tcp/Http/Udp
瀏覽器輸入url按回車背后經歷了哪些？
1.在PC瀏覽器的地址欄輸入一串URL，然后按Enter鍵這個頁面渲染出來，這個過程中都發生了什么事?
1、首先，在瀏覽器地址欄中輸入url，先解析url，檢測url地址是否合法
2、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存，如果緩存中有，會直接在屏幕中顯示頁面內容。若沒有，則跳到第三步操作。
瀏覽器緩存：瀏覽器會記錄DNS一段時間，因此，只是第一個地方解析DNS請求；
操作系統緩存：如果在瀏覽器緩存中不包含這個記錄，則會使系統調用操作系統，獲取操作系統的記錄(保存最近的DNS查詢緩存)；
路由器緩存：如果上述兩個步驟均不能成功獲取DNS記錄，繼續搜索路由器緩存；
ISP緩存：若上述均失敗，繼續向ISP搜索。
3、在發送http請求前，需要域名解析(DNS解析)，解析獲取相應的IP地址。
4、瀏覽器向服務器發起tcp連接，與瀏覽器建立tcp三次握手。
5、握手成功后，瀏覽器向服務器發送http請求，請求數據包。
6、服務器處理收到的請求，將數據返回至瀏覽器
7、瀏覽器收到HTTP響應
8、瀏覽器解碼響應，如果響應可以緩存，則存入緩存。
9、 瀏覽器發送請求獲取嵌入在HTML中的資源（html，css，javascript，圖片，音樂······），對於未知類型，會彈出對話框。
10、 瀏覽器發送異步請求。
11、頁面全部渲染結束。
GET和POST的區別
2.get和post請求區別，這個是被問爛的題了
首先這個題看似簡單，實際上是個送命題！如果你百度搜到的標准答案可能是這樣的（本標准答案參考自w3schools）：
- GET在瀏覽器回退時是無害的，而POST會再次提交請求。
- GET產生的URL地址可以被Bookmark，而POST不可以。
- GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
- GET請求只能進行url編碼，而POST支持多種編碼方式。
- GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留。
- GET請求在URL中傳送的參數是有長度限制的，而POST么有。
- 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
- GET比POST更不安全，因為參數直接暴露在URL上，所以不能用來傳遞敏感信息。
- GET參數通過URL傳遞，POST放在Request body中。
如果我告訴你，你死記硬背的這些所謂“標准答案”不是面試官想要的，你肯定不服，首先從安全性講，get和post都一樣，沒啥所謂的哪個更安全
get請求參數在url地址上，直接暴露，post請求的參數放body部分，按F12也直接暴露了，所以沒啥安全性可言
“GET參數通過URL傳遞，POST放在Request body中”這個其實也不准，post請求也可以沒body，也可以在url傳遞呢？
如果我告訴你get請求和post請求本質上沒區別，你肯定不信！
GET和POST有一個重大區別，簡單的說：
GET產生一個TCP數據包；POST產生兩個TCP數據包。
長的說：
對於GET方式的請求，瀏覽器會把http header和data一並發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
詳情可以參考這篇，寫的挺好的《GET和POST兩種基本請求方法的區別 》
cookies機制和session機制的區別
3.cookies機制和session機制的區別，這個也是經常會問的
- cookies數據保存在客戶端，session數據保存在服務器端；
- cookies可以減輕服務器壓力，但是不安全，容易進行cookies欺騙；
- session較安全，但占用服務器資源
HTTP狀態碼
4.HTTP狀態碼2xx,3xx,4xx,5xx分別是什么意思？這個是最基本的了，這個得熟練掌握，如果這個狀態碼都分不清，基本功就很弱了，印象分會大打折扣！
200 請求已成功，請求所希望的響應頭或數據體將隨此響應返回。 201 請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨Location 頭信息返回 202 服務器已接受請求，但尚未處理 301 （永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。 302 （臨時移動） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。 303 （查看其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。 304 （未修改） 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。 305 （使用代理） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。 307 （臨時重定向） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。 401 當前請求需要用戶驗證。如果當前請求已經包含了 Authorization 證書，那么401響應代表着服務器驗證已經拒絕了那些證書 403 服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重復提交 404 請求失敗，請求所希望得到的資源未被在服務器上發現 500 服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。 501 服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。 502 作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。 503 由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以后恢復。
http協議請求方式
5.http協議有哪幾種請求方式？
GET, POST 和 HEAD方、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
http和https區別
6.http和https區別？
HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全，為了保證這些隱私數據能加密傳輸，於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。
HTTPS和HTTP的區別主要如下：
總的來說： HTTPS=SSL+HTTP
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
（這個只是默認端口不一樣，實際上端口是可以改的）
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
報文
7.HTTP請求報文與響應報文格式
請求報文包含三部分：
a、請求行：包含請求方法、URI、HTTP版本信息
b、請求頭部（headers）字段
c、請求內容實體(body)
響應報文包含三部分：
a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語
b、響應頭部（headers）字段
c、響應內容(body)實體
post請求body
8.常見的 POST 提交數據方式
application/x-www-form-urlencoded
multipart/form-data
application/json
text/xml
DNS
9.什么是DNS？
域名解析服務。將主機名轉換為IP地址。如將http://www.cnblogs.com/主機名轉換為IP地址：211.137.51.78
無狀態
10.什么是Http協議無狀態協議?怎么解決Http協議無狀態協議?
(1)、無狀態協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息
(2)、無狀態協議解決辦法： 通過1、Cookie 2、通過Session會話保存。
三次握手過程理解
TCP是主機對主機層的傳輸控制協議，提供可靠的連接服務，采用三次握手確認建立一個連接:
序列號seq：占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號后，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。 確認號ack：占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最后一個字節的編號+1即為確認號。 確認ACK：占1位，僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效 同步SYN：連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標志位只有在TCP建產連接時才會被置1，握手完成后SYN標志位被置0。 終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接 PS：ACK、SYN和FIN這些大寫的單詞表示標志位，其值要么是1，要么是0；ack、seq小寫的單詞表示序號。
位碼即tcp標志位,有6種標示:
第一次握手：建立連接時，客戶端發送syn包（syn=x）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
四次揮手過程理解
四次揮手:
第一次揮手:客戶端A發送一個FIN.用來關閉客戶A到服務器B的數據傳送
第二次揮手:服務器B收到這個FIN. 它發回一個ACK，確認序號為收到的序號+1。和SYN一樣，一個FIN將占用一個序號
第三次揮手:服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A
第四次揮手:客戶端A發回ACK報文確認，並將確認序號設置為序號加1
1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2）服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最后的數據）。
4）服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
常見面試題
【問題1】為什么連接的時候是三次握手，關閉的時候卻是四次握手？
答：因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
【問題2】為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之后進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那么Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，則結束TCP連接。
【問題3】為什么不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發送數據的准備工作(雙方都知道彼此已准備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，並發 送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已准備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。
【問題4】如果已經建立了連接，但是客戶端突然出現故障了怎么辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75秒鍾發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接着就關閉連接。
文章來源：
https://blog.csdn.net/qq_41284481/article/details/103375225
https://www.cnblogs.com/xiyuan2016/p/14349037.html