計算機網絡（6） --- https協議_哈里沃克的博客-CSDN博客https協議https://blog.csdn.net/m0_63488627/article/details/132112683?spm=1001.2014.3001.5501

1.補充知識

1.PORT端口號

2.端口號范圍劃分

3.知名端口號

2.UDP協議

1.UDP報頭

2.UDP的特點

3.UDP的緩沖區

4.基于UDP的應用層協議

3.TCP協議?

1.TCP報頭?編輯

?報頭分離和解包分用

bind的作用

網絡協議棧和文件的關系

2.理解報頭

可靠性

工作模式的理解

發送數據大小限制

標志位

接收數據順序

4.丟包

5.三次握手四次揮手

1.三次握手

2.四次握手

3.各個階段的狀態

6.流量控制

7.滑動窗口

8.網絡阻塞

1.擁塞控制

2.擁塞窗口

3.最終決策

4.總結

9.應答的其他策略

延遲應答

捎帶應答

11.延申問題

面向字節流

粘包問題

TCP異常

?1.補充知識

1.PORT端口號

1.PORT端口號是為了確認運行的是服務器的哪個具體進程

2.在傳輸層，UDP和TCP協議的主要工作就是分離報文，將報頭的PORT找到，將數據傳輸給對應服務器的進程中運行

3.在TCP/IP協議中, 用 "源IP", "源端口號", "目的IP", "目的端口號", "協議號" 這樣一個五元組來標識一個通信(可以通過netstat -n查看);

2.端口號范圍劃分

1.0 - 1023: 知名端口號, HTTP, FTP, SSH等這些廣為使用的應用層協議, 他們的端口號都是固定的.
2.1024 - 65535: 操作系統動態分配的端口號. 客戶端程序的端口號, 就是由操作系統從這個范圍分配的.
3.對應的端口號操作其實不需要端口號也可以執行

3.知名端口號

1.ssh服務器, 使用22端口
2.ftp服務器, 使用21端口
3.telnet服務器, 使用23端口
4.http服務器, 使用80端口
5.https服務器, 使用443

2.UDP協議

1.UDP報頭

?1.要清楚的是：所謂的協議本質也是一種結構，UDP的協議結構就是如上圖。

2.16位UDP長度，表示整個數據報(UDP首部+UDP數據)的最大長度

3.如果校驗和出錯, 就會直接丟棄?

2.UDP的特點

UDP 傳輸的過程類似于寄信，發送和接收的永遠是一份完整的請求

1.無連接: 知道對端的IP和端口號就直接進行傳輸, 不需要建立連接;

2.不可靠: 沒有確認機制, 沒有重傳機制; 如果因為網絡故障該段無法發到對方, UDP協議層也不會給應用層返回任何錯誤信息;

3.面向數據報: 不能夠靈活的控制讀寫數據的次數和數量;也就意味著無法控制傳過來的數據的順序問題。

3.UDP的緩沖區

1.UDP沒有真正意義上的發送緩沖區.。調用sendto會直接交給內核, 由內核將數據傳給網絡層協議進行后續的傳輸動作;

2.UDP具有接收緩沖區. 但是這個接收緩沖區不能保證收到的UDP報的順序和發送UDP報的順序一致; 如果緩沖區滿了, 再到達的UDP數據就會被丟棄;

注意：我們注意到 , UDP 協議首部中有一個 16 位的最大長度 . 也就是說一個 UDP 能傳輸的數據最大長度是 64K( 包含 UDP 首部). 然而64K 在當今的互聯網環境下 , 是一個非常小的數字 . 如果我們需要傳輸的數據超過64K, 就需要在應用層手動的分包 , 多次發送 , 并在接收端手動拼裝 ;

4.基于UDP的應用層協議

NFS: 網絡文件系統

TFTP: 簡單文件傳輸協議

DHCP: 動態主機配置協議

BOOTP: 啟動協議 ( 用于無盤設備啟動 )

DNS: 域名解析協議。我們域名訪問是先訪問指定的域名服務器，找到對應的IP地址隨后進行訪問。

3.TCP協議?

又叫傳輸控制協議。

1.TCP報頭

?報頭分離和解包分用

1.由于TCP的標準報頭為20字節，那么分離出20字節。此時我們就有標準報文，將他轉換為指定的結構，就能提取出信息

2.將4為首部長度提取。所謂的首部長度是表示報頭大小的，具體是首部大小乘上4字節。也就是說報頭的大小范圍在20~60字節。此時具體的報頭就確定下來了

3.將端口號讀取出，發送給應用層特定的進程完成分用

4.其實報頭并沒有所謂的有效載荷大小，因為TCP是字節流，它發送數據，另一個主機接收可以知道傳過來的數據順序

bind的作用

bind用于綁定特定端口號的進程和報文。操作系統內部進程不僅僅是通過鏈表類似形式方便管理的，為了讓報文能輕易找到場景bind的進程端口高號，bind的過程就是通過hash算法將端口號和進程映射，那么此時我們如果想要找到曾經的端口號進程，只需要范圍哈希表即可

網絡協議棧和文件的關系

已知我們能通過bind找到對應的進程，進程由PCB管理，PCB中的文件描述符指向一個文件，該文件就是傳輸層傳來的數據。當我們把傳輸層的數據拷貝到文件中，也就意味著該數據緩沖到了進程的讀寫緩沖區中。

2.理解報頭

可靠性

1.不可靠的原因：網線太長

2.判斷可靠：確認應答，才算可靠。雙方通信，對歷史信息進行應答保證歷史信息是確認接收的，新數據沒有應答

工作模式的理解

有兩種發送模式，一種是不連續的發送；一種是連續發送

1.該發送模式是連續發送，那么接收到的結果其實很有可能是無序的狀態。那么我們需要一個標志來確定先后循環。當然，報頭的32位序號就是標識發送的數據順序。那么應答的數據也需要有確認對應的數據段，也就是報頭的32位確認序號。

2.確認序號+1=發送序號，舉例假如客戶端發送50號序號數據段，那么服務端則是發送51號確認序號確認50號發送序號。這是因為確認序號的定義為：接收方已經接收了確認序號之前的所有數據段，并且之前的數據段是連續的。如果10，11，12號發送過來，接收的確認序號是11，13，那么最終我們只能確認11號之前的全部接收到，并且應答，后面不能確定

3.一個報頭同時有序號和確認序號是為了全雙工。應答的一端也可以發送其他數據讓另一個接收。

發送數據大小限制

作為發送方其實有一點需要考慮，就是接收方是否有足夠的大小接收數據。但是這一點還是不夠的，因為發送和接收，使得緩沖區的大小是動態變換的。并且不知道對方主機的緩存區大小，所以報頭的16位窗口就是用來表示自己主機的傳輸層接收緩沖區大小的情況。那么一旦發送給另一端主機關于自己主機的緩沖區大小，發送的數據就會根據緩沖區進行調整。

標志位

tcp報文有各種類型，面對不同的tcp，接收方需要有不同的處理方法

不同的標志位表示不同的tcp類型

標志位
ACK: 確認號是否有效，用于應答
SYN: 請求建立連接; 我們把攜帶SYN標識的稱為同步報文段
FIN: 通知對方, 本端要關閉了, 我們稱攜帶FIN標識的為結束報文段
PSH: 提示接收端應用程序立刻從TCP緩沖區把數據讀走

ACK用于應答發送方的數據；SYN用于握手；FIN用于揮手，PSH用于將接收端的tcp接收緩沖區盡快處理。
RST: 對方要求重新建立連接; 我們把攜帶RST標識的稱為復位報文段

RST的作用是：在三次握手和四次揮手以及通信中時，建立連接失敗了。發送發發送請求，但是接收方不認為已經連接成功，那么就要發送RST進行三次握手重新建立連接

URG: 緊急指針是否有效，需要被盡快讀取的數據段

接收數據順序

1.由于從接收緩沖區中讀取的數據是先來先處理的，也就是說內部的結構是隊列。

2.那么每次傳過來的數據是按照傳輸的先后順序排列的

3.URG標志位一旦為真，表示需要被盡快讀取的數據段，那么該數據段就會插隊，優先被上層處理。而這個緊急指針其實是一個有效載荷的偏移量，偏移到指定的位置確認優先被處理。這樣的數據為帶外數據，但是只有一個字節。用于一些檢查，進程是否還在操作某個模塊可以用這個帶外數據進行檢查，而不需要進行漫長的處理字節流等待

4.丟包

丟包：數據發送過程中由于各種原因丟失

1.發送方將發送緩沖區的數據發送給接收方，接收方得到的數據都是由序號的，必須保證數據的完整性

2.對于發送方而言，其實沒有所謂的真正丟包一說，因為無法真正的確定。唯一能界定的標準就是時間上的維度，假設超過設定時間就默認判斷為丟包。

3.那么丟包了就需要發送方重新傳，所以發送方在一段時間內數據是不可以立馬刪除的。知道數據被應答說明發送成功，此時才不需要之前的數據，由操作系統自動釋放。

4.超過的時間也是不固定的，它是根據網絡情況浮動的

5.三次握手四次揮手

1.三次握手

1.客戶端將報頭的SYN置為1請求連接，發送報文

2.服務器接收，將報文的STN置為1請求連接和ACK置為1應答客戶端報頭SYN發送

3.客戶端將報文的ACK置為1，應答服務端報頭SYN發送

服務端和客戶端建立連接的時間有先后順序，并且三次握手不一定百分百成功

三次握手的原因：

1.我們要知道鏈接是要被記錄下來的，那么也就意味著需要被管理起來。OP管理鏈接先描述后組織是需要成本的。

2.如果只一次握手就算成功鏈接。那么客戶端可以不斷的向服務端發起SYN請求，服務端就要不斷的管理已經建立好的鏈接。SYN鏈接直接占著服務器的管理空間，使得可用的鏈接資源越來越少。這樣的問題就出現了SYN洪水

3.如果兩次握手。服務端發送ACK如果客戶端沒收到，那么客戶端仍然認為鏈接未建立，不斷發送SYN鏈接，此時就會出現上面的情況

4.三次握手成功的原因：三次握手是用最小的成本驗證全雙工的通信鏈接是已經被建立的，客戶端和服務端只要收到ACK應答就說明對方可以發送數據給自己主機；其次，三次握手可以有效防止單機進行對服務器進行攻擊。[服務器招到攻擊，本身tcp握手就無法解決。即SYN鏈接這種半鏈接也會消耗資源]

ddos攻擊：使用多臺主機(肉雞)同時訪問服務器，使得服務器鏈接資源完全被消耗而崩潰

5.偶數次一定失敗，因為客戶端的應答有時候無法被確定，造成和兩次握手情況一致；超過三次握手沒有必要，因為浪費時間。

2.四次握手

斷開連接是雙方的事情，所以兩邊都需要告知對方，自己不想發消息給對方

1.客戶端發送FIN給服務端

2.服務端對客戶端進行ACK

3.服務端發送FIN給客戶端

4.客戶端對服務端進行ACK，客戶端不發消息指的是不發用戶數據，而不是底層的鏈接消息

此外：tcp不知道數據是否已經發完了，但是用戶清楚，因為上層會將套接字文件close。只要close了，那么就說明不在通信。

面向鏈接之所以保證可靠性是因為：三次握手保證了雙方通信鏈接結構的完整，tcp的各種策略，重發、丟包等決策保證數據的完整性。二者同時實現數據傳輸的可靠性。

3.各個階段的狀態

建立連接一定是客戶端來請求服務端鏈接

1.最開始服務端為CLOSED狀態通過創造套接字，bind套接字；服務端為LISREN狀態，將套接字變為監聽套接字，再開啟accept創造套接字用于接收客戶端

2.客戶端第一次握手SYN_SENT狀態；服務端接收到變為SYN_RCVD，發送SYN+ACK；客戶端接受到則鏈接成功，發送ACK；服務器接收到也變為鏈接成功

斷開連接雙方都可以

1.誰先發出FIN，誰先變為FIN_WAIT1狀態；另一方收到就變為CLOSE_WAIT等待，并且發送ACK

2.接收方FIN_WAIT1狀態變為FIN_WAIT2。CLOSE_WAIT方發送FIN變為LAST_ACK狀態等待ACK；FIN_WAIT2狀態變為TIME_WAIT

3.最后LAST_ACK成為CLOSED狀態，不在發送消息。TIME_WAIT狀態一端過了一段時間后被動CLOSED（因為LAST_ACK需要等ACK，重新發）

注意：CLOSE_WAIT狀態有風險，因為如果另一方不發送ACK進行應答，那么本地就可能會有大量的CLOSE_WAIT文件。也就說明之前的接收套接字沒有被回收，文件描述符泄漏。其他客戶端無法鏈接。所以經過一段時間CLOSE_WAIT狀態會自動CLOSED，一般最長時間為2MSL(最大數據段在網絡的存活時間)

服務器重啟

1.服務器有時候可以立即重啟，有時候不能立即重啟的原因是：由于此時服務器的bind失敗，因為雖然綁定斷開，但是服務器鏈接還沒有結束，端口仍然存在所以不能立即重啟

2.服務器不能立即重啟有缺點，不能立即重啟會導致服務器不能讓客戶端鏈接，導致企業財產流失

3.設置重啟
int opt = 1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));//案例void initServer(){// 1. 創建socket文件套接字對象_listensock = socket(AF_INET, SOCK_STREAM, 0);if (_listensock < 0){exit(SOCKET_ERR);}// 1.1地址復用int opt = 1;setsockopt(_listensock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));// 2. bind綁定自己的網絡信息struct sockaddr_in local;memset(&local, 0, sizeof(local));local.sin_family = AF_INET;local.sin_port = htons(_port);local.sin_addr.s_addr = INADDR_ANY;if (bind(_listensock, (struct sockaddr *)&local, sizeof(local)) < 0){exit(BIND_ERR);}// 3. 設置socket 為監聽狀態if (listen(_listensock, gbacklog) < 0) // 第二個參數backlog后面在填這個坑{exit(LISTEN_ERR);}}

6.流量控制

流量控制：接收端處理數據的速度是有限的. 如果發送端發的太快, 導致接收端的緩沖區被打滿, 這個時候如果發送端繼續發送,就會造成丟包, 繼而引起丟包重傳等等一系列連鎖反應.因此TCP支持根據接收端的處理能力, 來決定發送端的發送速度. 這個機制就叫做流量控制

1.三次握手雙方就交換了窗口大小

2.兩邊在鏈接后也會不定期檢查對方的窗口大小進行動態的網絡吞吐

7.滑動窗口

1.應用層緩沖區會將自己的數據發送給tcp層的緩沖區中。

2.tcp層的傳輸緩沖區中存在滑動窗口。滑動窗口可以視作是一個數組，用于存放不同的數據。滑動窗口大小通過start和end的兩個標志位進行調節。

3.start之前的數據表示已經被發送并且已經得到應答的數據；滑動窗口的數據就是已經發送但是未應答的數據；end后有未發生的數據以及空數據的空間

4.start的移動是向右移動，不過前提是當前指向的位置數據是已經被應答的。我們要知道確認序號是指定的數據序號+1，確認序號的定義就是表示當前準確能被接收的數據的序號是確認序號之前的所有數據。那么一旦應答中確認了當前的確認序號的大小，start標記位就會被移動到指定未應答的區域。如果三次發送應答的數據都是一樣的，說明此時應答只能確定到當前位置，而滑動窗口中的數據有極高概率有丟失，那么此時就會需要重新傳數據。重傳的數據一定來自于滑動窗口內部。

5.end標志位，如果當前接受方的應答中表示自己的緩沖區沒有剩余空間存儲數據，那么end就不會移動，直到有空間。如果有內存，end會調整發送的大小，策略則是要進一步闡述(網絡阻塞中解釋)

6.那么也就是說滑動窗口的大小是不固定的

7.滑動窗口的結構是一個循環隊列。故空間不會因為移動而不斷變化。

8.滑動窗口的核心作用是用于提高tcp的發送效率。

8.網絡阻塞

1.擁塞控制

1.如果在剛開始階段就發送大量的數據, 可能引發問題。因為網絡上有很多的計算機, 可能當前的網絡狀態就已經比較擁堵. 在不清楚當前網絡狀態下, 貿然發送大量的數據,是很有可能引起雪上加霜的。而不讓主機發送大量數據的決策是擁塞控制

2.TCP引入慢啟動機制, 先發少量的數據, 探探路, 摸清當前的網絡擁堵狀態, 再決定按照多大的速度傳輸數據；

2.擁塞窗口

1.網絡中會設置一個擁塞窗口，該結構表明網絡中傳輸的數據上限，一旦超過這個數，很有可能出現網絡阻塞

2.每次發送數據包的時候, 將擁塞窗口和接收端主機反饋的窗口大小做比較, 取較小的值作為實際發送的窗口。所以滑動窗口需要根據窗口大小和擁塞窗口之間比較進行決策。
3.慢啟動：發送開始的時候, 定義擁塞窗口大小為1；每次收到一個ACK應答, 擁塞窗口大小翻倍;

4.慢啟動的意義：使得網絡快速的恢復，一旦恢復就立即快速處理數據

3.最終決策

指數增張過快，所以需要引入慢啟動的閾值

1.當 TCP 開始啟動的時候 , 慢啟動閾值等于窗口最大值 ;

2.在每次超時重發的時候 , 慢啟動閾值會變成原來的一半 , 同時擁塞窗口置回1

4.總結

1.少量的丟包 , 我們僅僅是觸發超時重傳 ; 大量的丟包 , 我們就認為網絡擁塞 ;

2.當 TCP 通信開始后 , 網絡吞吐量會逐漸上升 ; 隨著網絡發生擁堵 , 吞吐量會立刻下降 ;

3.擁塞控制 , 歸根結底是 TCP 協議想盡可能快的把數據傳輸給對方 , 但是又要避免給網絡造成太大壓力的折中方案

9.應答的其他策略

延遲應答

1.如果接收數據的主機立刻返回 ACK 應答 , 這時候返回的窗口可能比較小。此時接收方不立即應答，先處理緩沖區的數據，等待一段時間有可能會將窗口大小變大，剩余空間多了，那么ACK返回的窗口大小也更大。這樣有利于提高效率

2.延遲應答條件

數量限制: 每隔N個包就應答一次

時間限制: 超過最大延遲時間就應答一次

捎帶應答

互相發送消息的同時順帶將對方數據的應答ACK也帶上，是比較常見的提高效率策略。

11.延申問題

面向字節流

1.應用層的數據傳輸到傳輸無非是將數據拷貝到傳輸層

2.tcp協議傳輸到接收方，接收方是無法明確報頭的。因為tcp協議一視同仁，面向字節流的意思就是讀取的時候幾字節幾字節的讀取。并且tcp報文沒有記錄有效載荷的大小，這是因為序列的存在直接保證數據的順序發送，而不需要在乎里面的內容是什么。

3.udp不同，udp面向數據包，只有接受到完整報文的說法，而不存在半個這種情況。

4.讀取和發送其實都是交給操作系統，而操作系統管理發多少，不在于人的設置。

粘包問題

1.由于tcp面向字節流，我們無法對數據進行分離。也就出現報文讀取的不完整性，因為讀無法保證，在tcp看來報文與報文之間無所謂的區別，這就是粘包問題。

2.粘包問題的解決不在tcp，而在應用層，應用層可以讀取分離出數據，所以需要發送者先規定好報文和報文之間的界限，已到達應用層讀取數據后可以進行區分報文的情況

TCP異常

1.進程結束：進程結束之前會將鏈接斷開

2.關機：其實也是一種進程結束，只是操作系統自行幫忙釋放的，與進程結束邏輯一致

3.斷電，斷網：一方斷開，另一方不知道并且仍然保持鏈接，另一方會發送報文進行確認是否還在運行，一旦超時或者接收不到應答就會自己釋放鏈接

listen的第二個參數

第二個參數：表示當前文件描述符被套接字占滿，其余的一部分套接字等待連接。參數設置表示發送方先于接收方建立鏈接，而接收方先不鏈接發送發的個數。

全鏈接：雙方都鏈接成功

半鏈接：一方成功。未鏈接的一方狀態為SYN_RECV

1.如果長期未連接雙方也還是會斷開。

2.隊列長度為設置的flag+1