理論與API相結合理解Node中的網絡通訊

關注公衆號「 執鳶者」，獲取大量教學視頻及 私人總結麪筋（公衆號原創文章）並進入 專業交流羣

隨着Node發展，其應用愈來愈常見，特別是在咱們前端圈，給咱們注入了新的活力。在使用中，Node的網絡通訊部分主要涉及到傳輸層和應用層，本次就來一塊兒嘮一嘮常見的TCP、UDP、HTTP協議的使用，經過理論與實踐相結合，更加清楚的瞭解與使用這些協議。

1、傳輸層

1.1 TCP

TCP是面向鏈接的，而且經過流量控制、、序號、確認和定時器，確保正確的、按序的將數據從發送進程交付給接收進程。按照服是否進行監聽進行劃分，TCP分爲服務器和客戶端。下面來分開聊一下。

認真讀Node的API，發現其與TCP的原理暗暗貼合，媽媽不再用擔憂我記不住這些API了。先看看TCP的三次握手與四次揮手過程。

• 三次握手

1. TCP服務器進程先建立傳輸控制塊TCB（線程控制塊），時刻準備接受客戶進程的鏈接請求，此時服務器就進入了LISTEN（監聽）狀態；
2. TCP客戶進程也是先建立傳輸控制塊TCB，而後向服務器發出鏈接請求報文，這時報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。
3. TCP服務器收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。
4. TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。
5. 當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始通訊了。

• 四次揮手

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.1.1 TCP服務器

在上述圖中，仔細品，能夠總結爲如何建立服務、服務相關、鏈接相關。而後並將其中事件與三次握手、四次揮手進行聯繫，很容易發現其實關鍵過程都被進行了監聽。

1. 如何建立服務：TCP創建鏈接前須要進入監聽狀態，因此這就涉及到圖中的建立方式，建立服務後才能夠監聽特定地址
2. 服務相關：服務建立以後就要觀察其狀態，並根據其狀態進行一些列的處理，這就是服務器事件作的事情。
3. 鏈接相關：服務器監聽的目的是有鏈接創建並進行通訊，當鏈接創建以後就須要對整個數據傳輸過程進行監聽，這就是鏈接事件。

1.1.2 TCP客戶端

TCP客戶端作的事情比較簡單，只須要與對應服務器創建鏈接，便可進行數據的傳輸了。

1.1.3 注意事項

1.2 UDP

一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務.

2、應用層

2.1 HTTP

HTTP應該是平常開發中用的最多的協議，其是創建在TCP傳輸層之上的應用層協議。搞懂這個協議對前端總體水平的提升相當重要。

2.1.1 服務器

2.1.2 客戶端

2.1.3 兩個關鍵對象

IncomingMessage和ServerResponse兩個對象在整個協議的使用中直觀重要，特別是IncomingMessage。當咱們在使用的時候，是否是不懂的如何去使用，這個時候是否是應該去考慮一下請求報文與響應報文的結構了？我的認爲其 關鍵屬性恰好與請求報文和響應報文相呼應。

1. HTTP請求報文主要包括：請求行（方法字段、URI字段和協議版本）、請求頭部以及請求的數據（實體）。
2. HTTP響應報文分爲三個部分：狀態行（版本、狀態碼和緣由語句）、首部行和實體。

歡迎老鐵們加羣或者私聊