web工程師應該懂的計算機網絡知識，TCP

OSI七層參考模型

OSI（Open System Interconnection）參考模型是國際標準化組織（ISO）制定的一個用於計算機或通信系統間互聯的標準體系，一般稱為OSI參考模型或七層模型。

應、表、會、傳、網、數、物

1. 應用層： 直接和應用程序接口，為應用進程提供服務。其作用是在實現多個系統應用進程相互通信的同時，完成一系列業務處理所需的服務。（網絡服務與最終用戶的一個接口）如HTTP/FTP/SMTP/POP3
2. 協議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
3. 表示層：在數據傳輸之前，對加密、解密、壓縮、解壓縮、格式化、代碼轉換、安全等提供一套約定和規則。
4. 格式有，JPEG、ASCll、DECOIC、加密格式等
5. 會話層：對會話的雙方進行資格審查和校驗，同時規定發送時的雙工模式。會話層使用校驗點可使通信會話在通信失效時從校驗點繼續恢復通信。
6. 傳輸層：接受會話層的數據，在必要的時候把數據進行分割，並將這些數據交給網絡層，在兩個實體之間建立端到端可靠的通信信道，以及流控和差錯校驗。TCP UDP，數據包一旦離開網卡即進入網絡傳輸層。
7. 網絡層：負責建立、保持和終止通過中間設備的連接，實現不同網絡之間的路徑選擇、擁擠控制，為數據包選擇路由。IP協議屬於該層。路由器、交換機。
8. 數據鏈路層：將數據組裝成幀，幀是本層的傳輸單位，為數據在傳輸過程中建立邏輯連接、進行硬件地址尋址、差錯校驗，調節發送速率使之與接收方匹配。mac地址
9. 物理層： 建立、維護、斷開物理連接，以二進制數據形式在物理媒體上傳輸數據。包括設備之間物理連接的接口、用戶設備與網絡終端設備之間的傳輸規則。

TCP/IP四層模型

1. 應用層：
2. 負責處理特定的應用程序細節。包括Telnet（遠程登錄）、FTP（文件傳輸協議）、SMTP（簡單郵件傳送協議）以及SNMP（簡單網絡管理協議）等。
3. 傳輸層：

• 主要為兩臺主機上的應用程序提供端到端的通信。在TCP/IP協議族中，有兩種傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。
• TCP為兩臺主機提供高可靠性的數據通信。它所做的工作包括把應用程序交給它的數據分成合適的小塊交給下面的網絡層，設置發送最後確認分組的超時時鐘等。
• UDP為應用層提供一種非常簡單的服務。它只是把稱作數據報的分組從一臺主機發送到另一臺主機，但並不保證該數據報能到達另一端。任何必需的可靠性必須由應用層來提供。
• 特點：
• 1、由應用程序產生應用進程，由應用進程產生進程端口號，由端口號提供相應的服務。
• 2、TCP發送進程以字節流的形式傳遞數據，而接收進程也把數據作為字節流來接收，類似於假想的管道
• 3、UDP發送進程發送的數據報文都是獨立的，因此UDP不是面向流的協議
• 4、緩存：數據流向的每一個方向上都有兩種緩存：發送緩存、接收緩存
• 5、在傳輸層向IP層發送數據時要以分組為單位，而不是按字節流來發送，TCP協議把若干字節構成一個分組，我們可以把這樣的分組稱為報文段( segment)，這種報文段並不一定都一樣長，可以幾個字節，也可以是幾千個字節

1. 網絡層：
2. 也稱作網絡互聯層，處理分組在網絡中的活動，例如分組的選路。在TCP/IP協議族中，網絡層協議包括IP協議（網際協議），ICMP協議（Internet互聯網控制報文協議），以及IGMP協議（Internet組管理協議）。
3. 數據鏈路層：
4. 也稱作網絡接口層，通常包括操作系統中的設備驅動程序和計算機中對應的網絡接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細節。

• PDU: Protocol dateⅦnit:表示對等層之間傳遞的數據單位
• TCP: Transmission control protoco1:傳輸控制協議
• UDP: User Dategram Protoco1:用戶數據報協議
• IP: Internet protocol:互聯網報文協議
• ICMP: Internet Control Message Protocol:互聯網控制報文協議
• ping、traceroute 差錯通知、信息查詢
• ARP: Address resolution protocol:地址解析協議
• 用於將計算機的網絡P地址轉化為物理MAC地址。ARP協議的基本功能就是通過目標設備的P地址，查詢目標設備的MAC地址，以保證通信的順利進行。在每臺安裝有TCP/P協議的電腦裡都有個ARP緩存表，表裡的P地址與MAC地址是—對應的。
• RARP: Reverse Address resolution protocol:反向地址解析協議
• 使只知道自己硬件地址的主機能夠知道其IP地址，這種主機往往是無盤工作站。因此RARP協議目前已很少使用。

IP協議

IP提供不可靠的，無連接的數據傳送服務。 不可靠指它不能保證IP數據報能成功到達目的地。

不可靠：它不能保證IP數據報能成功地到達目的地。如果發生某種錯誤時，如某個路由器暫時用完了緩衝區，IP有一個簡單的錯誤處理算法：丟棄該數據報，然後發送ICMP消息報給信源端。任何要求的可靠性必須由上層來提供（如TCP）。

無連接：IP並不維護任何關於後續數據報的狀態信息。每個數據報的處理是相互獨立的。這也說明，IP數據報可以不按發送順序接收。如果一信源向相同的信宿發送兩個連續的數據報（先是A，然後是B），每個數據報都是獨立地進行路由選擇，可能選擇不同的路線，因此B可能在A到達之前先到達。

TCP協議

特點

TCP協議的特點：

1. 面向連接；
2. TCP提供可靠交付的服務；
3. 面向字節流。面向字節流的含義：雖然應用程序和TCP交互是一次一個數據塊，但TCP把應用程序交下來的數據僅僅是一連串的無結構的字節流。
4. 每一條TCP連接只能有兩個端點，每一條TCP連接只能是點對點的；
5. TCP提供全雙工通信。數據在兩個方向上獨立的進行傳輸。因此，連接的每一端必須保持每個方向上的傳輸數據序號；

套接字（socket、插口、套接口）地址：包含 IP地址和端口

TCP的三次握手

1. 第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
2. 第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
3. 第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入連接成功ESTABLISHED(established)狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

客戶端：“喂，聽得到嗎？”

服務器：“聽到了，你能聽到我講話嗎？”

客戶端：“很清楚，我們開始聊天吧。”

TCP的四次揮手

由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

（1）第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

（2）第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

（3）第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

客戶端：“我要斷開連接了。”

服務器：“好的。”

服務器：“我也要斷開連接了。”

客戶端：“好的。”

簡述 HTTP 協議的工作流程

1. 地址解析;
2. 在瀏覽器中輸入 URL，瀏覽器會從中分解出協議名、主機名、端口、對象路徑等部分
3. 封裝 HTTP 請求數據包
4. 瀏覽器獲取主機 IP 地址，建立 TCP 鏈接（TCP 的三次握手）
5. TCP 鏈接建立後發送 HTTP 請求
6. 請求方式的格式為：統一資源標識符（URL）、協議版本號，後邊是 MIME 信息包括請求修飾符、客戶機信息和可能的內容。
7. 服務器接到請求後，給予相應的響應信息
8. 其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是 MIME 信息包括服務器信息、實體信息和可能的內容
9. 服務器斷開 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報文。

問題3：為什麼不能用兩次握手進行連接？

為了實現可靠數據傳輸， TCP 協議的通信雙方，雙方都知道彼此已準備好，同時都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟。

​如果只是兩次握手， 至多隻有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。

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

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

狀態詳解

LISTEN：偵聽來自遠方的TCP端口的連接請求

SYN-SENT：再發送連接請求後等待匹配的連接請求（客戶端）

SYN-RECEIVED：再收到和發送一個連接請求後等待對方對連接請求的確認（服務器）

ESTABLISHED：代表一個打開的連接

FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認

FIN-WAIT-2：從遠程TCP等待連接中斷請求

CLOSE-WAIT：等待從本地用戶發來的連接中斷請求

CLOSING：等待遠程TCP對連接中斷的確認

LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認

TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認

CLOSED：沒有任何連接狀態

UDP協議

用戶數據報協議（User Datagram Protocol，UDP）UDP是OSI參考模型中一種無連接的傳輸層協議，它主要用於不要求分組順序到達的傳輸中，分組傳輸順序的檢查與排序由應用層完成 ，提供面向事務的簡單不可靠信息傳送服務。

特點

1. 面向事物，不是面向鏈接。
2. UDP不提供可靠性：它把應用程序傳給IP層的數據發送出去，但是並不保證它們能到達目的地。簡單的可以理解UDP就是類似一個郵寄員的角色。你只要告訴它，對方的地址和電話。郵遞員就把你的快遞送到對應的地方，但是中間可能會丟失。對方收到沒有，就不管了。

UDP 是一個簡單的傳輸層協議。和 TCP 相比，UDP 有下面幾個顯著特性：

• UDP 缺乏可靠性。UDP 本身不提供確認，序列號，超時重傳等機制。UDP 數據報可能在網絡中被複制，被重新排序。即 UDP 不保證數據報會到達其最終目的地，也不保證各個數據報的先後順序，也不保證每個數據報只到達一次
• UDP 數據報是有長度的。每個 UDP 數據報都有長度，如果一個數據報正確地到達目的地，那麼該數據報的長度將隨數據一起傳遞給接收方。而 TCP 是一個字節流協議，沒有任何（協議上的）記錄邊界。
• UDP 是無連接的。UDP 客戶和服務器之前不必存在長期的關係。UDP 發送數據報之前也不需要經過握手創建連接的過程。
• UDP 支持多播和廣播。

HTTP協議

特性

1. HTTP構建於TCP/IP協議之上，默認端口號是80
2. HTTP是無連接無狀態的，就是每次的請求和之後的請求都是沒有關係的。

組成

請求：狀態行、請求頭、消息主體

響應：狀態行、響應頭、響應正文

常見狀態碼

• 100：繼續 客戶端應當繼續發送請求。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。
• 101： 轉換協議 在發送完這個響應最後的空行後，服務器將會切換到在Upgrade 消息頭中定義的那些協議。只有在切換新的協議更有好處的時候才應該採取類似措施。
• 102：繼續處理 由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行。
• 200 OK 客戶端請求成功
• 301 Moved Permanently 請求永久重定向
• 302 Moved Temporarily 請求臨時重定向
• 304 Not Modified 文件未修改，可以直接使用緩存的文件。
• 400 Bad Request 由於客戶端請求有語法錯誤，不能被服務器所理解。
• 401 Unauthorized 請求未經授權。這個狀態代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden 服務器收到請求，但是拒絕提供服務。服務器通常會在響應正文中給出不提供服務的原因
• 404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL
• 500 Internal Server Error 服務器發生不可預期的錯誤，導致無法完成客戶端的請求。
• 502 Bad Gateway 錯誤的網關，作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
• 503 Service Unavailable 服務器當前不能夠處理客戶端的請求，這個狀況是臨時的，在一段時間之後，服務器可能會恢復正常。

常見請求\\響應頭

• Content-Type
• Accept
• Origin
• Cookie
• Cache-Control
• User-Agent
• Referrer
• X-Forwarder-For
• Access-Control-Allow-Origin
• Last-Modified

HTTP協議請求方法

• GET
• POST
• HEAD：跟GET方法相同，只不過服務器響應時不會返回消息體。
• OPTIONS：獲取服務器支持的HTTP請求方法；用來檢查服務器的性能
• PUT
• DELETE
• TRACE：超文本傳輸協議，定義的一種協議調試方法，該方法會使服務器原樣返回任意客戶端請求的任何內容。

HTTP的基本優化

影響一個HTTP網絡請求的因素主要有兩個：帶寬和延遲。

• 帶寬：撥號上網的階段帶寬可能會成為一個比較嚴重影響請求的問題，但是現在影響的可能性小。
• 延遲：
• 瀏覽器阻塞（HOL blocking）：瀏覽器對於同一個域名，同時只能有 4 個連接（這個根據瀏覽器內核不同可能會有所差異），超過瀏覽器最大連接數限制，後續請求就會被阻塞。
• DNS 查詢（DNS Lookup）：這個通常可以利用DNS緩存結果來達到減少這個時間的目的。
• 建立連接（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連接，但是這些連接無法複用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

HTTP1.0和HTTP1.1的一些區別

HTTP1.0最早在網頁中使用是在1996年，HTTP1.1是當前使用最為廣泛的HTTP協議。

主要區別主要體現在：

1. 緩存處理，在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
2. 帶寬優化及網絡連接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
3. 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
4. Host頭處理，在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
5. 長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。

HTTPS

HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定義在RFC 6101中，之後IETF對SSL 3.0進行了升級，於是出現了TLS（Transport Layer Security） 1.0，定義在RFC 2246。實際上我們現在的HTTPS都是用的TLS協議，但是由於SSL出現的時間比較早，並且依舊被現在瀏覽器所支持，因此SSL依然是HTTPS的代名詞。

握手過程：

1. 客戶端發起一個https的請求，把自身支持的一系列Cipher Suite（密鑰算法套件，簡稱Cipher）發送給服務端；
2. 服務端接收到客戶端所有的Cipher後與自身支持的對比，如果不支持則連接斷開，反之則會從中選出一種加密算法和HASH算法，並將自己的身份信息以證書的形式發回給客戶端。證書中還包含了公鑰、頒證機構、網址 失效日期等等。
3. 客戶端獲得網站證書之後瀏覽器要做以下工作：

• 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
• 生成隨機密碼：如果證書受信任，或者是用戶接受了不受信的證書，客戶端會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
• 使用約定好的HASH算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給服務端。

1. 服務端接收客戶端發來的數據之後要做以下的操作：

• 使用自己的私鑰將信息解密取出密碼，使用密碼解密客戶端發來的握手消息，並驗證HASH是否與客戶端發來的一致。
• 使用密碼加密一段握手消息，發送給客戶端。

1. 客戶端解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通信數據將由之前客戶端生成的隨機密碼並利用對稱加密算法進行加密。

HTTPS一般使用的加密與HASH算法如下：

1. 非對稱加密算法：RSA，DSA/DSS
2. 對稱加密算法：AES，RC4，3DES
3. HASH算法：MD5，SHA1，SHA256

HTTPS與HTTP的一些區別

1. HTTPS協議需要到CA申請證書；
2. HTTP協議運行在TCP之上，所有傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的；
3. HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443；
4. HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。
5. HTTP2.0

• 新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯。
• 多路複用（MultiPlexing），即連接共享，每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裡面。
• header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重複發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的大小。
• 服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數網站已經啟用HTTP2.0，例如YouTuBe，淘寶等網站，利用chrome控制檯可以查看是否啟用H2

Websocket

WebSocket是為解決客戶端與服務端實時通信而產生的技術。websocket協議本質上是一個基於tcp的協議，是先通過HTTP/HTTPS協議發起一條特殊的http請求進行握手後創建一個用於交換數據的TCP連接，此後服務端與客戶端通過此TCP連接進行實時通信。

簡介

1. 服務器可以主動向客戶端推送信息；
2. 建立在TCP協議上，服務端比較容易實現；
3. 性能開銷比較小，通信高效；
4. 可以發送文本，也可以發送二進制數據；

Websocket和HTTP協議的關係

同樣作為應用層的協議，WebSocket在現代的軟件開發中被越來越多的實踐，和HTTP有很多相似的地方，這裡將它們簡單的做一個純個人、非權威的比較：

相同點

1. 都是基於TCP的應用層協議。
2. 都使用Request/Response模型進行連接的建立。
3. 在連接的建立過程中對錯誤的處理方式相同，在這個階段WS可能返回和HTTP相同的返回碼。
4. 都可以在網絡中傳輸數據。

1. WS使用HTTP來建立連接，但是定義了一系列新的header域，這些域在HTTP中並不會使用。
2. WS的連接不能通過中間人來轉發，它必須是一個直接連接。
3. WS連接建立之後，通信雙方都可以在任何時刻向另一方發送數據。
4. WS連接建立之後，數據的傳輸使用幀來傳遞，不再需要Request消息。
5. WS的數據幀有序。

什麼是 Socket？工作流程是怎樣的？

Socket 又稱網絡套接字，是一種操作系統提供的進程間通信機制。

工作流程：

1. 服務端先用 socket 函數來建立一個套接字，並調用 listen 函數，使服務端的這個端口和 IP 處於監聽狀態，等待客戶端的連接
2. 客戶端用 socket 函數建立一個套接字，設定遠程 IP 和端口，並調用 connect 函數
3. 服務端用 accept 函數來接受遠程計算機的連接，建立起與客戶端之間的通信
4. 完成通信以後，最後使用 close 函數關閉 socket 連接。

HTTP中GET與POST的區別，注意最後一條

1. GET在瀏覽器回退時是無害的，而POST會再次提交請求。
2. GET產生的URL地址可以被Bookmark，而POST不可以。
3. GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
4. GET請求只能進行url編碼，而POST支持多種編碼方式。
5. GET請求參數會被完整保留在瀏覽器歷史記錄裡，而POST中的參數不會被保留。
6. GET請求在URL中傳送的參數是有長度限制的，而POST沒有。
7. 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
8. GET比POST更不安全，因為參數直接暴露在URL上，所以不能用來傳遞敏感信息。
9. GET參數通過URL傳遞，POST放在Request body中。
10. GET產生一個TCP數據包，POST產生兩個TCP數據包。

Cookie存在哪

1. 如果設置了過期時間，Cookie存在硬盤裡
2. 沒有設置過期時間，Cookie存在內存裡

COOKIE和SESSION的區別和關係

1. COOKIE保存在客戶端，而SESSION則保存在服務器端
2. 從安全性來講，SESSION的安全性更高
3. 從保存內容的類型的角度來講，COOKIE只保存字符串（及能夠自動轉換成字符串）
4. 從保存內容的大小來看，COOKIE保存的內容是有限的，比較小，而SESSION基本上沒有這個限制
5. 從性能的角度來講，用SESSION的話，對服務器的壓力會更大一些
6. SEEION依賴於COOKIE，但如果禁用COOKIE，也可以通過url傳遞

nginx的負載均衡實現方式

1. 輪詢
2. 用戶IP哈希
3. 指定權重
4. fair（第三方）
5. url_hash（第三方）

網絡IO模型

1. 阻塞IO
2. 非阻塞IO
3. 多路複用IO
4. 信號驅動IO
5. 異步IO

阻塞IO

場景描述：

老李去火車站買票，排隊三天買到一張退票。

網絡模型：

在這個模型中，應用程序為了執行這個read操作，會調用相應的一個system call，將系統控制權交給內核，然後就進行等待（這個等待的過程就是被阻塞了），內核開始執行這個system call，執行完畢後會嚮應用程序返回響應，應用程序得到響應後，就不再阻塞，並進行後面的工作。

優點：能夠及時返回數據，無延遲。

缺點：對用戶來說處於等待就要付出性能代價。

非阻塞IO

場景描述：

老李去火車站買票，隔12小時去火車站問有沒有退票，三天後買到一張票。

網絡模型：

當用戶進程發出read操作時，調用相應的system call，這個system call會立即從內核中返回。但是在返回的這個時間點，內核中的數據可能還沒有準備好，也就是說內核只是很快就返回了system call，只有這樣才不會阻塞用戶進程，對於應用程序，雖然這個IO操作很快就返回了，但是它並不知道這個IO操作是否真的成功了，為了知道IO操作是否成功，應用程序需要主動的循環去問內核。

優點：能夠在等待的時間裡去做其他的事情。

缺點：任務完成的響應延遲增大了，因為每過一段時間去輪詢一次read操作，而任務可能在兩次輪詢之間的任意時間完成，這對導致整體數據吞吐量的降低。

多路複用IO

場景描述：

1. select/poll：老李去火車站買票，委託黃牛，然後每隔6小時電話黃牛詢問，黃牛三天內買到票，然後老李去火車站交錢領票。
2. epoll：老李去火車站買票，委託黃牛，黃牛買到後即通知老李去領，然後老李去火車站交錢領票。

網絡模型：

IO多路轉接是多了一個select函數，select函數有一個參數是文件描述符集合，對這些文件描述符進行循環監聽，當某個文件描述符就緒時，就對這個文件描述符進行處理。

IO多路轉接是屬於阻塞IO，但可以對多個文件描述符進行阻塞監聽，所以效率較阻塞IO的高。

信號驅動IO

場景描述：

老李去火車站買票，給售票員留下電話，有票後，售票員電話通知老李，然後老李去火車站交錢領票。

網絡模型：

應用進程告訴內核：當數據報準備好的時候，給我發送一個信號，對SIGIO信號進行捕捉，並且調用我的信號處理函數來獲取數據報。

異步IO

場景描述：

老李去火車站買票，給售票員留下電話，有票後，售票員電話通知老李並快遞送票上門。

網絡模型：

當應用程序調用aio_read時，內核一方面去取數據報內容返回，另一方面將程序控制權還給應用進程，應用進程繼續處理其他事情，是一種非阻塞的狀態。

當內核中有數據報就緒時，由內核將數據報拷貝到應用程序中，返回aio_read中定義好的函數處理程序。