1、三次握手四次揮手過程？ ## 簡述 TCP 三次握手？ * 第一次握手：建立連接時，客戶端發送syn包到服務器，并進入SYN_SENT狀態，等待服務器確認 * 服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態； * 客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態 服務器收到確認報文段之后，也進入已建立連接狀態 ## 簡述TCP 四次揮手？ * 客戶端應用進程發出連接釋放報文段，并停止再發送數據，進入 FIN-WAIT-1(終止等待1)狀態，等待服務器確認 * 服務器收到連接釋放報文段后即發出確認，進入 CLOSE-WAIT(關閉等待)狀態，服務器若發送數據，客戶端扔要接收 * 客戶端收到來自服務器的確認后，進入 FIN-WAIT-2(終止等待2)狀態，等待服務器發出連接釋放報文段 * 服務器沒有要發送的數據，發出連接釋放報文段，進入 LAST-ACK(最后確認)狀態，等待客戶端確認 * 客戶端收到連接釋放報文段后，發出確認，進入 TIME-WAIT(時間等待)狀態，經過時間等待計時器設置的時間 2MSL 后，進入 CLOSED(關閉) 狀態 * 服務器收到客戶端報文段后，進入 CLOSED 狀態 2、為什么不能兩次握手、或者3次揮手 ## 為什么TCP建立連接握手是3次，揮手需要4次？ 因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。 ### 為什么不能用兩次握手進行連接？ 答：3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。 現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，并發 送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。 ## 3、udp和tcp的區別？特點？  ### UDP 的主要特點 * UDP 是`無連接的`，即發送數據之前不需要建立連接(發送數據結束時也沒有連接可釋放)，減少了開銷和發送數據之前的時延 * UDP 使用`盡最大努力交付`，即不保證可靠交付，主機不需要維持復雜的連接狀態表 * UDP 是`面向報文`的，發送方的 UDP 對應用程序交下來的報文，在添加首部后就向下交付 IP 層。UDP 對應用層交下來的報文，既不合并，也不拆分，而是`保留這些報文的邊界` * UDP`沒有擁塞控制`，網絡出現的擁塞不會使源主機的發送速率降低。這對某些實時應用是很重要的 * UDP 支持一對一、一對多、多對一和多對多的交互通信 * UDP 的`首部開銷小`，只有8個字節，比 TCP 的20個字節的首部要短 ### TCP 的主要特點 * TCP 是`面向連接的運輸層協議`。應用程序在使用 TCP 協議之前，必須先建立 TCP 連接。在傳送數據完畢后，必須釋放已經建立的 TCP 連接 * 每一條 TCP 連接只能有兩個`端點`，每一條 TCP 連接只能是`點對點`的(一對一) * TCP 提供`可靠交付`的服務。通過 TCP 連接傳送的數據，無差錯、不丟失、不重復，并且按序到達 * TCP 提供`全雙工通信`。TCP 允許通信雙方的應用進程在任何時候都能發送數據。TCP 連接的兩端都設有發送緩存和接受緩存，用來臨時存放雙向通信的數據 * `面向字節流`。TCP 中的“流”指的是`流入到進程或從進程流出的字節序列 4、websocke是怎么建立連接的，升級請求包含哪些內容？ 1. Client發送一個 ‘upgrade' request，這是一個http請求，使用的是http協議。 2. Server返回一個http 101，代表請求成功。 5、http協議一次請求包含哪些內容？（請求頭） ## 6、http和https的區別？https的加密方式？ * https協議需要到CA（Certificate Authority，證書頒發機構）申請證書，一般免費證書較少，因而需要一定費用。 * http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。 * http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。 * http的連接很簡單，是無狀態的。Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。(無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無連接的意思是指通信雙方都不長久的維持對方的任何信息。) ## 7、一次網頁輸入地址到展示的完整過程？ 0、瀏覽器本地緩存匹配； 1、本地hosts映射對比; 2、本地dns緩存解析； 3、遠程dns解析獲得服務器ip地址； 4、瀏覽器發送tcp連接請求包(syn)； 5、請求包經過傳輸層、網絡層、數據鏈路層封裝通過網卡到達路由器； 6、路由器轉發數據包到所屬運營商服務器； 7、運營商服務器通過尋址最短路徑通過中繼節點到達指定ip地址； 8、服務器端可能存在反向代理或者負載均衡，都是直接轉發請求至上游服務器，當然也可以制定安全防御規則直接丟棄請求包； 9、上游服務器收到連接請求，在自身可用的情況下，返回(syn+ack)； 10、瀏覽器校驗ack，再次發送(syn+ack)； 11、服務器校驗ack切換連接狀態至established，然后根據請求傳輸數據包； 12、當transform-encoding為chunked時，瀏覽器開始渲染頁面； 13、四次揮手，連接關閉； 14、渲染數據完成。 ## 8、get和post的區別？ 1. get 請求一般用于向服務端獲取數據，post 一般向服務端提交數據 2. get 傳輸的參數在 url 中，傳遞參數大小有限制，post 沒有大小限制， 3. get 不安全，post 安全性比get高 4. get請求在服務端用Request.queryString 接受 ,post 請求在服務端用Requset.form 接受 5. get是兩段提交，先是返回100，之后再提交返回200，post直接就是200 ## 9、網絡七層模型和五大網絡io模型？（各部分包含什么協議和作用）  * 應用層：應用層協議定義的是應用進程間通信和交互的規則 * 運輸層：運輸層的任務就是負責向`兩臺主機中進程之間的通信`提供`通用的數據傳輸`服務 * 網絡層：把運輸層產生的報文段或用戶數據報封裝成`分組`或`包`進行傳送 * 數據鏈路層：將網絡層交下來的 IP 數據報組裝成幀，并在兩個相鄰結點間的鏈路上傳送 * 物理層：利用物理媒體以`比特`形式傳送數據 ## 10、http的常見狀態碼？代表什么？怎么解決？ 200（成功）服務器已成功處理了請求。 301（永久移動） 302（臨時移動） 304 - Not Modified.(未修改)自從上次請求后，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容是客戶端有緩存情況下，服務端的一種響應，提升用戶體驗。 403 - Forbidden 訪問被拒絕 權限不足（chmod -R 777 /data） 404 - 請求的網頁不存在 500 - 大多是代碼問題，或者sql報錯 501 - 服務器不具備完成請求的功能 502 - Bad Gateway fpm進程掛掉或者后端程序過長時間未返回。 503 - Service Unavailable 當遇到這個狀態碼的時候表示服務臨時不可用，比如nginx配置了頻率限制，而client端又超過了配置的限制后就會收到503的響應。 504 - Gateway Time-out nginx的fastcgi模塊有一個fastcgi_read_timeout配置，它表示從FastCGI server獲取數據的超時時間。如果超過這個配置客戶端就是收到504的響應。 ## 11、建立 TCP 連接為什么最后還要發送確認？ 這主要是為了防止已失效的連接請求報文段突然又傳到了 TCP 服務器，避免產生錯誤。 ## 12、TIME-WAIT 是什么，為什么必須等待 2MLS？ 雖然按道理，四個報文都發送完畢，我們可以直接進入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連接。 ## 13、為什么TCP建立連接握手是3次，揮手需要4次？ 因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。 ## 14、如果已經建立了連接，但是客戶端突然出現故障了怎么辦？ TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。 ## 15、客戶端在使用HTTPS方式與Web服務器是怎么通信的？ 1. 客戶端請求服務器，服務器返回數字證書（里面包括，服務器公鑰，網站地址，證書頒發機構），數字證書本身使用證書私鑰加密 2. 解密證書，驗證證書數字簽名，通過操作系統和瀏覽器內置的CA證書信息。驗證通過后，客戶端生成一個隨機密碼，用接收到的服務器公鑰將其加密，發送到服務器 3. 用服務器私鑰解密，得到隨機密碼 4. 握手結束，之后的通信全部使用隨機密碼進行對稱加密通信 ## 16、WebSocket是什么？ WebSocket 是一種通信協議，定義了一個全雙工通信信道，僅通過 Web 上的一個 Socket 即可進行通信，主要特點 推送功能：支持由服務器向客戶端推送數據的推送功能 減少通信量：只要建立起 WebSocket 連接，就希望一直保持連接狀態 ## 17、什么是心跳機制？ 心跳機制是定時發送一個自定義的結構體(心跳包)，讓對方知道自己還活著，以確保連接的有效性的機制。 ## 18、HTTP 請求頭部信息有哪些？ 請求頭部由關鍵字/值對組成，每行一對 1. User-Agent :客戶端信息 2. Accept : 客戶端希望接受的數據類型，比如 Accept：application/json 3. Connection ：?表示是否需要持久連接，比如Keep-Alive 4. Host : 請求的主機名，允許多個域名同處一個IP地址，即虛擬主機 5. Cookie：瀏覽器端cookie ## 19、建立 TCP 連接為什么最后還要發送確認？ 這主要是為了防止已失效的連接請求報文段突然又傳到了 TCP 服務器，避免產生錯誤。 20、滑動窗口？ ## 21、TCP/IP 網絡擁塞怎么解決 * TCP -【擁塞控制】- 快重傳、快恢復 * TCP - 擁塞控制方法 * **慢開始（slow start，慢啟動）** * **擁塞避免（congestion avoidance）** * **快速重傳（fast retransmit）** * **快速恢復（fast recovery）** ## 22、TCP協議可靠性是如何保證 * **序列號和確認應答信號** * **超時重發控制** * **連接管理** * **滑動窗口控制** * **流量控制** * **擁塞控制** * **序列號和確認應答信號** seq 表示當前段序列號，ack代表下一段開始位置（seq+1） * **超時重發控制** **重發超時是指在重發數據之前，等待確認應答到來的那個特定時間間隔**。如果超過這個時間仍未收到確認應答，發送端將進行數據重發。 * **連接管理** 即三次握手四次揮手 * **滑動窗口控制**  **窗口大小就是指無需等待確認應答ACK而繼續發送數據的最大值**。 這種窗口機制實現了使用了大量的緩沖區（Buffer，指的是計算機存儲收發數據的的內存空間），通過對多個段同時進行確認應答的功能。  對于滑動窗口有以下幾點特點： * 上圖中的窗口內的數據即便沒有收到確認應答也可以被發送出去。不過，**在整個窗口的確認應答沒有到達之前，如果其中部分數據出現丟包，那么發送端仍然要負責重傳**。為此，發送端主機需要**設置緩存保留這些待被重傳的數據，直到收到他們的確認應答**。 * 在滑動窗口以外的部分包括未發送的數據以及已經確認對端已收到的數據。當數據發出后若如期收到確認應答就可以不用再進行重發，此時數據就可以從緩存區清除。 * 收到確認應答的情況下，將窗口滑動到確認應答中的序列號的位置。**這樣可以順序地將多個段同時發送提高通信性能。這種機制也別稱為滑動窗口控制**。 ### 擁塞控制與流量控制的區別 * **流量控制**是作用于接收者的，它是控制發送者的發送速度從而使接收者來得及接收，防止丟失數據包的。 * **擁塞控制**擁塞控制是作用于網絡的，它是防止過多的數據注入到網絡中，避免出現網絡負載過大的情況 * **流量控制** TCP需要提供一種機制：**讓發送端根據接收端實際的接收能力控制發送的數據量**。這就是所謂的流量控制。 TCP 利用**滑動窗口**實現流量控制的機制， 而滑動窗口大小是通過TCP首部的窗口大小字段來通知對方。 窗口大小的內容實際上是接收端接收數據緩沖區的剩余大小。**這個數字越大，證明接收端接收緩沖區的剩余空間越大，網絡的吞吐量越大。** 不過，當接收端這個接收緩沖區面臨數據溢出時，窗口大小的值就會隨之設置成一個更小值，告訴發送端要控制一下發送的數據量了。 **流量控制的具體操作就是**：接收端會在確認應答發送ACK報文時，將自己的即時窗口大小rwnd（receiver window）填入，并跟隨ACK報文一起發送過去。而發送方根據ACK報文里的窗口大小的值進而改變自己的發送速度。  **發送端停止發送數據后，什么時候可以繼續發送數據呢？** 我們繼續看上圖，答案就是等接收端處理完了緩沖區的數據后發送一個**窗口更新**的數據包通知，發送端才可以繼續根據窗口大小發送數據。 **但是如果發送端在重發超時的時間內都沒有收到窗口更新的通知或者窗口更新的包丟失了，就沒法正常通信了，那怎么辦呢？** TCP為每一個連接設有一個**持續計時器(persistence timer)。**只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口控測數據段（這個數據段只包含一個字節），那么收到這個報文段的一方就重新設置持續計時器。 所以發送端會定時向接收端發送一個**窗口探測**的數據段，這目的是為了獲取最新的窗口大小信息。 * **擁塞控制** #### 什么是擁塞 我們都知道計算機網絡中的資源是有限的。某段時間內網絡中對資源的需求超過了網絡中的可用部分，而導致網絡性能下降的情況就是擁塞。 通俗點說就是發送的數據包太多網絡中的設備處理不過來，而導致網絡性能下降的情況。 #### TCP 為什么要進行擁塞控制 網絡中的路由器會有一個數據包處理隊列，當路由器接收到的數據包太多而一下子處理不過來時，就會導致數據包處理隊列過長。此時，路由器就會無條件的丟棄新接收到的數據封包。 這就會導致上層的 TCP 協議以為數據包在網絡中丟失，進而重傳這些數據包，而路由器又會丟棄這些重傳的數據包，如此以往，就會導致網絡性能急劇下降，引起網絡癱瘓。因此，TCP 需要控制數據包發送的數量來避免網絡性能的下降。 #### 擁塞控制原理 有了TCP的滑動窗口控制，收發主機之間即使不再以一個“段”為單位，而是以一個“窗口”為單位發送確認應答信號，所以發送主機夠連續發送大量數據包。然而，**如果在通信剛開始的時候就發送大量的數據包，也有可能會導致網絡的癱瘓。** 在擁塞控制中，發送方維持一個叫做**擁塞窗口cwnd**（congestion window）的狀態變量。**擁塞窗口的大小取決于網絡的擁塞程度，并且動態地在變化**。 發送窗口取擁塞窗口和接收端窗口的最小值，避免發送接收端窗口還大的數據。 擁塞控制使用了兩個重要的算法：**慢啟動算法**，**擁塞避免算法**。 **慢啟動算法**： 慢啟動算法的思路是，不要一開始就發送大量的數據，先試探一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。慢算法中，**每個傳輸輪次后將 cwnd 加倍**。慢啟動，不是指擁塞窗口增長慢，而是相對于一開始就上來傳輸大窗口的數據要顯得慢。 **擁塞避免算法**： 擁塞避免算法也是逐漸的增大 cwnd 的大小，只是采用的是**線性增長**而不是像慢啟動算法那樣的指數增長。 具體來說就是每個傳輸輪次后將 cwnd 的大小加一（加法增大），如果發現出現網絡擁塞的話就按照上面的方法重新設置ssthresh的大小（乘法減小，原來的二分之一）并從cwnd=1開始重新執行慢開始算法。 ### 慢啟動算法和擁塞避免算法結合： 問題：在擁塞控制中， 慢啟動算法 和 擁塞避免算法 是怎么配合使用的呢？ 像上面所說，慢啟動算法下的cwnd大小是指數增長，所以不能任 cwnd 任意增長，所以我們引入一個慢啟動門限（ssthresh）的閾值來控制 cwnd 的增長。 ssthresh的作用是： * 當cwnd < ssthresh時，使用慢開始算法。 * 當cwnd > ssthresh時，改用擁塞避免算法。 * 當cwnd = ssthresh時，慢開始與擁塞避免算法隨機 還有一個問題就是這個 ssthresh 是怎么設置的呢？ **TCP/IP 中規定無論是在慢開始階段還是在擁塞避免階段，只要發現網絡中出現擁塞（沒有按時收到確認），就要把ssthresh設置為此時發送窗口的一半大小**（不能小于2）。  擁塞控制的大致流程如下： * 一開始把ssthresh初始值設置成16，開始慢啟動增加擁塞窗口cwnd，直到cwnd=16 停止慢啟動，開始擁塞避免算法。 * 使用擁塞避免算法線性增加cwnd，直到cwnd=24，這時候網絡出現擁塞（ACK確認信號沒有及時到達），把ssthresh設置成原來的一半，也就是ssthresh=12，同時把cwnd設為1。 * 重新開始慢啟動，直到cwnd到達ssthresh=12，然后執行擁塞避免算法進行加法增大，直到遇到網絡擁塞，把ssthresh調成原來的一一半。 * 如此反復動態計算cwnd，以達到擁塞控制的目的。 #### 快重傳 VS 超時重傳 TCP 的可靠傳輸的原理就是超時重傳機制，而重發機制有兩種：**超時重傳機 和 快重傳** * **TCP超時重傳機制**，結合上面說的**慢啟動**和**擁塞避免**使用就是發送完數據后開始倒計時，如果在**重發超時內**沒有收到對接收方發來的ACK的話就去執行上述的**乘法減小過程（設置sstresh為原來一半）**并重新開始慢開始算法，重新發送數據。 * **TCP快重傳**， 則是允許發送方再連續收到**3 個重復的確認**后就可以開始執行乘法減小過程而不必再等待重發超時時間。這就需要接收方每收到一個**失序**的報文段就立即發出重復確認以讓發送方及早知道有報文段丟失，而不是等待自己發送數據的時候進行捎帶確認。  由于發送端不必等待每個數據段都確認才能繼續發送，而是以一個窗口為單位發送數據，所以就算主機A發送的1001-2000序列號數據段丟失，主機A依然會繼續發剩下的窗口大小數據，而此時主機B發現1001-2000數據丟失，它會每次收到其他序列號的數據包，都返回一個序列號1000的ACK，以此明確通知主機A，當主機A收到**三次**1000的ACK直到丟失了1001-2000數據包，就需要重傳1001-2000的數據包了。 以此達到哪怕沒到重發超時時間，都能快速重傳的目的 #### 快恢復 **快恢復算法是與快重傳算法配合使用的一個算法。** 快恢復主要是指，當快重傳的時候，發送方快速收到了**3個重復的確認**，因此會認為網絡不是擁塞狀態，所以在**乘法減小過程（設置sstresh為原來一半）**，會啟動**“擁塞避免”**，而不是TCP超時重發機制的重新啟動的**慢啟動** **TCP協議在實現傳輸可靠性上面做了很多：** * 通過**序列號和確認應答信號**確保了數據不會重復發送和重復接收。 * 同時通過**超時重發控制**保證即使數據包在傳輸過程中丟失，也能重發保持數據完整。 * 通過三次握手，四次揮手建立和關閉連接的**連接管理**保證了端對端的通信可靠性。 * TCP還使用了**滑動窗口控制**提高了數據傳輸效率 * 通過**流量控制**控制發送者的發送速度從而使接收者來得及接收，防止丟包。 * 通過**擁塞控制**就是防止過多的數據注入到網絡中，避免網絡中的路由器或鏈路不致過載，導致數據丟失。從而保證了TCP傳輸的可靠性。 ## 為什么選擇在傳輸層就將數據“大卸八塊”分成多個段，而不是等到網絡層再分片傳遞給數據鏈路層？ 因為可以提高重傳的性能 需要明確的是：可靠傳輸是在傳輸層進行控制的 如果在傳輸層不分段，一旦出現數據丟失，整個傳輸層的數據都得重傳 如果在傳輸層分了段，一旦出現數據丟失，只需要重傳丟失的那些段即可