網絡基礎總結

網絡分層

TCP的四層

• 應用層： 規定向用戶提供應用服務時通訊協議。 如DNS
• 傳輸層： 提供處於網路鏈接中兩臺計算機之間的數據傳輸所使用的協議。在傳輸層有兩個性質不一樣的協議TCP和UDP
• 網絡層： 規定了數據經過怎麼樣的傳輸路線到對方計算機傳送給對方。如IP協議
• 鏈路層： 用來處理鏈接網絡硬件的部分，包括操做系統、硬件設備的驅動、網卡等

OSI七層模型
SI七層模型|功能|對應的網絡協議|TCP/IP四層概念模型
:--:|:--:|:--:|:--:
應用層|文件傳輸，文件管理，電子郵件的信息處理——apdu|HTTP、TFTP, FTP, NFS, WAIS、SMTP|應用層
表示層|確保一個系統的應用層發送的消息能夠被另外一個系統的應用層讀取，編碼轉換，數據解析，管理數據的解密和加密，最小單位——ppdu|Telnet, Rlogin, SNMP, Gopher|應用層
會話層|負責在網絡中的兩節點創建，維持和終止通訊，在一層協議中，能夠解決節點鏈接的協調和管理問題。包括通訊鏈接的創建，保持會話過程通訊鏈接的暢通，兩節點之間的對話，決定通訊是否被終端一斤通訊終端是決定從何處從新發送，最小單位——spdu|SMTP, DNS|應用層
傳輸層|定義一些傳輸數據的協議和端口。傳輸協議同時進行流量控制，或是根據接收方接收數據的快慢程度，規定適當的發送速率，解決傳輸效率及能力的問題——tpdu|TCP, UDP|傳輸層
網絡層|控制子網的運行，如邏輯編址，分組傳輸，路由選擇最小單位——分組（包）報文|IP, ICMP, ARP, RARP, AKP, UUCP|網絡層
數據鏈路層|主要是對物理層傳輸的比特流包裝，檢測保證數據傳輸的可靠性，將物理層接收的數據進行MAC（媒體訪問控制）地址的封裝和解封裝，也能夠簡單的理解爲物理尋址。交換機就處在這一層，最小的傳輸單位——幀|FDDI, Ethernet, Arpanet, PDN, SLIP, PPP，STP。HDLC,SDLC,幀中繼|數據鏈路層
物理層|定義物理設備的標準，主要對物理鏈接方式，電氣特性，機械特性等制定統一標準，傳輸比特流，所以最小的傳輸單位——位（比特流）|IEEE 802.1A, IEEE 802.2到IEEE 802.|數據鏈路層

1、TCP

簡介

TCP是傳輸控制協議，基於TCP的應用層有HTTP、SMTP、FTP協議等

特色

• 面向鏈接、面向字節流、全雙共通道、可靠。
• 面向鏈接：使用TCP傳輸數據前，必須先創建TCP鏈接，傳輸完成後在釋放鏈接
• 全雙共通道：創建TCP鏈接後，通訊雙方都能發送數據
• 可靠：經過TCP鏈接傳送的數據：不丟失、無差錯、不重複、按序到達
• 面向字節流：數據以流的形式進行傳輸

優缺點

• 優勢：數據傳輸可靠
• 缺點：效率慢（因需創建鏈接、發送確認包等）

創建鏈接 3次握手

• 第一次握手：客戶端向服務器發送一個鏈接請求的報文段。報文段信息包括：同步標誌位(SYN)設爲一、隨機選擇一個起始序號(seq)爲x、不攜帶數據。客戶端進入同步已發送狀態(SYN_SEND),等待服務器的確認
• 第二次握手：服務器收到請求鏈接報文段後，若贊成創建鏈接，則向客戶端發回鏈接確認的報文段。報文段信息包括：同步標誌位(SYN)設爲一、確認標記位(ACK)爲一、隨機選擇一個起始序號(seq)爲y、確認號字段(ack)爲x+一、不攜帶數據。服務器進入同步已接受狀態(SYN_RCVD)
• 第三次握手：客戶端收到確認報文字段後，向服務器再次發出鏈接確認報文段。報文段信息包括：確認標記位(ACK)爲一、序號(seq)爲x+一、確認號字段(ack)爲y+一、可攜帶數據。客戶端、服務段都進如已建立狀態，可開始發送數據
  

注意：成功進行TCP的三次握手後，就創建一條TCP鏈接，可傳送應用層數據。

由於TCP提供的全雙工通訊，故通訊雙發的應用進程在任什麼時候候都能發送數據。三次握手期間，任何一次未收到對面的回覆，則都會重發。

爲何TCP創建鏈接須要三次握手？

防止服務器端因接收了早已失效的鏈接請求報文，從而一隻等待客戶端請求，最終致使造成死鎖、浪費資源

描述以下：

• 客戶端發出的第一個鏈接請求報文段無丟失，而是在某個網絡結點長時間滯留了，致使延誤到鏈接釋放後的某個時間纔到達服務器。
• 致使延誤到鏈接釋放後的某個時間纔到達服務器
• 這是一個早已失效的報文段，可是服務器不知道，服務器收到此失效的鏈接請求報文段後，就誤覺得是客戶端再次發出的一個新的請求，因而向客戶端發出了確認報文段，贊成創建TCP鏈接
• 假設不採用「三次握手」，即服務器發出確認報文段後，TCP鏈接就創建了，但因爲客戶端並沒有發出創建鏈接的請求，所以不會向服務器發送數據，因對於客戶端來講，該報文已失效了，可是服務器卻覺得新的TCP鏈接已創建，因而一直等待客戶端發送數據，即死鎖狀態
• 創建鏈接= 採用「三次握手」，即關鍵是第三次握手。
• 在上面的狀況，客戶端不會向服務器的確認報文信息，再次發出確認。服務器因爲收不到客戶端的確認信息，即知道客戶端並沒有要求創建TCP鏈接，故服務器不會一直等待客戶端發送數據，即不會造成死鎖狀態

SYN洪泛濫：

服務器的TCP資源分配時刻=完成第二次握手時，而客戶端的TCP資源分配時刻 = 完成第三次握手時，這使得服務器易於受到SYN洪泛攻擊，即同時多個客戶端發起鏈接請求，從而需進行多個請求的TCP鏈接資源分配。

斷開須要四次揮手

在通訊結束後，雙方均可以釋放鏈接，共需四次握手。
釋放TCP鏈接前。TCP客戶端、服務器都處於已建立狀態（ESTABLISHED），直到客戶端主動關閉TCP鏈接

• 第一次揮手：客戶端向服務器發起一個鏈接釋放的報文段（中止在發送數據）。報文段信息：終止控制(FIN)設爲一、報文段序號，設爲前面傳送數據最後一個字節的序號加1（seq = u）,可攜帶數據（FIN = 1的報文幾時不攜帶數據也消耗一個序號）。客戶端進入終止等待1狀態。（FIN-WAIT-1）
• 第二次握手：服務器收到鏈接釋放報文段後，則向客戶端發回鏈接釋放確認的報文段。報文段信息：確認標記位設爲1: ACK=一、報文段序號，設爲前面傳送數據最後一個字節的序號加1（seq = v），確認號字段設爲：ack= u+1。服務器進入關閉等待狀態（CLOSE-WAIT）,客戶端收到服務器的確認後，進入終止等待2狀態（FIN-WAIT-2），等待服務器發出釋放鏈接請求。至此，客戶端->服務器的TCP鏈接已斷開，即TCP鏈接處於半關閉的狀態，即客戶端->服務器斷開，但服務器->客戶端未斷開
• 第三次握手：若服務器已無要向客戶端發送數據，則發出釋放鏈接的報文段。報文段信息：終止控制(FIN)設爲一、確認標記位設爲1：ACK=1，報文段序號，設爲（seq = w）,重複上次已發送的確認號字段設爲：ack = u+一、可攜帶數據（FIN = 1的報文即便不攜帶數據也消耗一個序號）。服務器進入最後確認狀態（LAST-ACK）
• 第四次握手：客戶端收到鏈接釋放報文段後，則向服務器發回鏈接釋放確認的報文段。報文段信息：確認標記位設爲1:ACK=一、報文段序號：seq = u + 一、確認號字段爲：ack = w + 一、可攜帶數據（FIN = 1的報文幾時不攜帶數據也消耗一個序號）。 客戶端進入等待時間狀 態（TIME-WAIT），服務器進入關閉狀態（COLSE），此時TCP鏈接還未釋放，必須通過時間等待計時器設置的時間2MSL後，客戶端才進入鏈接關閉狀態（CLOSED），即服務器進入關閉狀態比客戶端要早一些。

爲何TCP釋放鏈接需4次揮手？

• 爲了保證通訊雙方都能通知對方。需釋放和斷開鏈接。
• 當主機1發出「釋放鏈接請求」、主機2返回「確認釋放鏈接」信息時，只表示主機1已無數據要發送到主機2，但主機2仍是能夠發送數據給主機1，主機1仍是能夠接受主機2的數據，即單向斷開
  
• 當主機2也發送了「釋放鏈接請求」、主機1返回「確認釋放鏈接」信息時，表示主機2已無數據要發送到主機1，此時雙發都沒法通訊，即TCP鏈接纔算真正釋放（雙向）

爲何客戶端關閉鏈接前要等待2MSL時間？

即TIME-WAIT狀態的做用是什麼？MSL = 最長報文壽命（Maximum Segment Lifttime）

緣由1:爲了保證客戶端發送的最後一個請求鏈接釋放確認報文能到達服務器，從而使得服務器能正常釋放鏈接。解析：以下：

• 客戶端發送的最後一個鏈接釋放確認報文可能會丟失，當服務器收不到最後一個鏈接釋放確認報文時，則不會進入關閉狀態，但會超時重發，鏈接釋放報文。
  
• 假設：客戶端不等待2MSL時間就直接進行關閉狀態（CLOSED），當最後一個鏈接釋放確認報文丟失、服務器重發鏈接釋放報文時，客戶端則沒法接收到服務器從新發送的鏈接釋放報文時，客戶端則沒法接收到服務器從新發送的鏈接釋放報文，所以也不會發送鏈接釋放確認報文段，最終致使服務沒法進入關閉狀態（CLOSED）。
• 客戶端發送最後一個鏈接釋放確認後哦，先等待2MSL時間，在進入關閉狀態（CLOSE），此時客戶端則接收到服務器從新發送的鏈接釋放報文，從而發送鏈接釋放確認報文段，會從新啓動2MSL計時器，使得服務器能正常進入關閉狀態（CLOSED）

緣由2:防止上文提到的早已失效的鏈接請求報文出如今本鏈接中，客戶端發送了最後一個鏈接釋放請求確認報文後，再通過2MSL時間，則可以使本鏈接持續時間內所產生的全部報文段都從網絡中消失。即在下一個新的鏈接中就不會出現早已失效的鏈接請求報文。

TCP無差錯傳輸？

相對於UDP，TCP的傳輸是可靠的、無差錯的。

對於發送端：每收到一個確認幀，發送窗口就向前滑動一個幀的距離，當發送窗口內無可發送的幀時（即窗口內的幀所有是已發送但未收到確認的幀），發送方就會中止發送，直到收到接收方發送的確認幀使窗口移動，窗口內有能夠發送的幀，以後才能夠繼續發送。

對於接收端：當收到數據幀後，將串口向前移動一個位置，並返回確認幀，若收到的數據落在窗口以後，則一概丟棄。

發送窗口：定義：任意時刻，發送方維持的一組連續的、容許發送幀的幀序號。做用：對發送方進行流量控制。

接收串口：定義：任意時刻，接收方維持的一組連續的、容許接收幀的幀序號。做用：控制可接收哪些數據，不可接收哪些數據幀；接收方只有當收到的數據的序號落入接收窗口內才容許將該數據幀手下；不然，一概丟棄。

TCP和UDP的區別

TCP：面向鏈接、可靠、字節流（傳輸形式）、傳輸速率慢、所需資源多、要求通訊數據可靠，首部字節在20-60

UPD：無鏈接、不可靠、數據報文段（傳輸形式）、傳輸速率快、所需資源少、要求通訊速度快，首部字8個字節（由4個字段組成）

2、UDP

面向無鏈接

UDP是不須要和 TCP 同樣在發送數據前進行三次握手創建鏈接的，想發數據就能夠開始發送了。而且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操做。

具體來講：

• 在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增長一個 UDP 頭標識下是 UDP 協議，而後就傳遞給網絡層了
• 在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操做

不可靠性

• 不可靠性體如今無鏈接上，通訊都不須要創建鏈接，想發就發。
• 收到什麼數據就傳遞什麼數據，而且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。
• 網絡環境時好時壞，可是 UDP 由於沒有擁塞控制，一直會以恆定的速度發送數據。即便網絡條件很差，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件很差的狀況下可能會致使丟包，可是優勢也很明顯，在某些實時性要求高的場景（好比電話會議）就須要使用 UDP 而不是 TCP。

高效

UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。
UDP 頭部包含了如下幾個數據

• 兩個十六位的端口號，分別爲源端口（可選字段）和目標端口
• 整個數據報文的長度
• 整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤

傳輸方式
UDP 不止支持一對一的傳輸方式，一樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

3、HTTP

1.簡介和特色

http：超文本傳輸協議，完成從客戶端到服務器等一些系列運做流程。web是創建在http協議上的通訊。

特色：

• http是不保存狀態的協議，既無狀態協議。協議自己對於請求或響應之間的通訊狀態不進行保存，所以鏈接雙方不能知曉對方當前的身份和狀態。這也是Cookie技術產生的重要緣由之一：客戶端的狀態管理。瀏覽器會根據從服務器端發送的響應報文內 Set-Cookie 首部字段信息自動保持 Cookie。而每次客戶端發送 HTTP 請求，都會在請求報文中攜帶 Cookie，做爲服務端識別客戶端身份狀態的標識。
• 無鏈接，即交換http報文前，不須要創建HTTP鏈接http協議是TCP/IP協議的一個子集.http採用TCP做爲運輸層協議。

2.http請求報文。

http的請求報文有請求行、請求頭、請求體組成
請求行： 聲明請求方法、主機域名、路徑資源、協議版本
請求頭：聲明客戶端、服務器、等報文的部分信息
請求體：存放需發送的數據信息

報文結構以下：