計算機網絡匯總

本文轉載自查看原文 2021-08-09 21:24 124 計算機網絡

計算機網絡體系結構
TCP
UDP
- 特點
- 報文段格式
HTTP
Socket
在瀏覽器中輸入url地址 ->> 顯示主頁的過程
其他知識
無差錯傳輸
參考鏈接

計算機網絡體系結構

主要講解TCP/IP體系結構：

TCP

Transmission Control Protocol，即傳輸控制協議

1.屬於傳輸層通信協議

2.基於TCP的應用層協議有HTTP、SMTP、FTP、Telnet 和 POP3

特點

建立連接過程（三次握手）

報文格式

首部前20個字符固定、后面有4n個字節是根據需而增加的選項

故 TCP首部最小長度 = 20字節

為什么要三次握手

三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

第一次握手：Client 什么都不能確認；Server 確認了對方發送正常；

第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己接收正常，對方發送正常

第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送接收正常

所以三次握手就能確認雙發收發功能都正常，缺一不可。

SYN：同步序列編號（Synchronize Sequence Numbers）。是TCP/IP建立連接時使用的握手信號。

為什么要傳回 SYN

接收端傳回發送端所發送的 SYN 是為了告訴發送端，我接收到的信息確實就是你所發送的信號了。

傳了 SYN,為啥還要傳 ACK

雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方到接收方的通道沒有問題，但是接收方到發送方的通道還需要 ACK 信號來進行驗證。

SYN 同步序列編號（Synchronize Sequence Numbers）是 TCP/IP 建立連接時使用的握手信號。

ACK(Acknowledgement) 確認字符 ,在數據通信傳輸中，接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤。

SYN(synchronous建立聯機)

ACK(acknowledgement 確認)

PSH(push傳送) FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼)

SYN表示建立連接，FIN表示關閉連接，ACK表示響應，PSH表示有 DATA數據傳輸，RST表示連接重置。

釋放連接過程

為什么要四次揮手

舉個例子：A 和 B 打電話，通話即將結束后：

1.A 說“我沒啥要說的了”，

2.B回答“我知道了”，但是 B 可能還會有要說的話，A 不能要求 B 跟着自己的節奏結束通話，

3.於是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，

4.A 回答“知道了”，這樣通話才算結束。

因為是“全雙工”，所以需要倆邊都斷開了連接

為什么需要等待 2MSL

MSL（Maximum Segement Lifetime）

因為如果不等待的話，如果服務端還有很多數據包要給客戶端發，且此時客戶端端口被新應用占據，那么就會接收到無用的數據包，造成數據包混亂，所以說最保險的方法就是等服務器發來的數據包都死翹翹了再啟動新應用。

1個 MSL 保證四次揮手中主動關閉方最后的 ACK 報文能最終到達對端
1個 MSL 保證對端沒有收到 ACK 那么進行重傳的 FIN 報文能夠到達

UDP

User Datagram Protocol，即用戶數據報協議

屬於傳輸層通信協議

基於UDP的應用層協議有 TFTP、SNMP 與 DNS

特點

報文段格式

HTTP

HTTP協議屬於應用層

特點

工作方式

HTTP協議采用 請求 / 響應 的工作方式
具體工作流程如下：

HTTP報文詳解

請求報文

報文結構

請求行

結構
請求行的組成 = 請求方法 + 請求路徑 + 協議版本

注：空格不能省

此處特意說明GET、PSOT方法的區別：

請求頭

采用”header（字段名）：value（值）“的方式

1. 請求和響應報文的通用Header

常見請求Header

請求體

作用：存放需發送給服務器的數據信息
使用方式：共3種

總結

響應報文

報文結構

狀態行

組成
狀態行有協議版本、狀態碼 &狀態信息組成

其中，空格不能省

具體介紹

響應頭

類似

響應體

類似

HTTP 與HTTPS的區別

HTTP1.0 與 HTTP1.1的區別

主要區別主要體現在：

緩存處理，

在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標准，

HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
帶寬優化及網絡連接的使用，

HTTP1.0中，存在一些浪費帶寬的現象，

例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，

HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，

如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；

410（Gone）表示服務器上的某個資源被永久性的刪除。
Host頭處理，在HTTP1.0中認為每台服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。

但隨着虛擬主機技術的發展，在一台物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。

HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，

在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，

在HTTP1.1中默認開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。

HTTP 2 改進

改進性能：

頭部壓縮
多路信道復用
Server Push

HTTP長連接

Connection： keep-alive

Socket

即套接字，是應用層與 TCP/IP 協議族通信的中間軟件抽象層，表現為一個封裝了 TCP / IP協議族的編程接口（API）

Socket不是一種協議，而是一個編程調用接口（API），屬於傳輸層（主要解決數據如何在網絡中傳輸）

對用戶來說，只需調用Socket去組織數據，以符合指定的協議，即可通信

成對出現，一對套接字：

Socket ={(IP地址1:PORT端口號)，(IP地址2:PORT端口號)}

一個 Socket 實例唯一代表一個主機上的一個應用程序的通信鏈路

在瀏覽器中輸入`url`地址 ->> 顯示主頁的過程

其他知識

IP地址（IPv4地址）

定義連接在Internet中的每一台主機（或路由器）的全球唯一的標識符
組成 IP地址 = 32位 = 網絡號 + 主機號；即IP地址::={<網絡號>，<主機號>}

其中：

網絡號：標志主機（或路由器）所連接到的網絡。一個網絡號在整個因特網范圍內必須是唯一的。

主機號：標志該主機（或路由器）。一個主機號在它面前的網絡號所指明的網絡范圍必須是唯一的。

不同類型的IP地址，其主機號 & 網絡號所占字節數不同；故：一個IP地址在整個網絡范圍內是唯一的

分類傳統的IP地址是分類的地址，分為A，B，C，D，E五類

區別在於網絡號 & 主機號占的字節數不同

特別注意：在各類IP地址中，有一些IP地址用於特殊用途，不能用於做主機IP地址

ICMP協議

定義 Internet Control Message Protocol，即網際控制報文協議

屬於IP層協議

注：ICMP報文不是高層協議，而是作為IP層數據報的數據，加上數據報首部，組成IP數據報發出去

作用更有效地轉發IP數據包 & 提高交付成功的機會

同時允許主機 / 路由器報告差錯 & 異常情況

分類 ICMP差錯報告報文 & ICMP詢問報文
主要應用 PING（分組網間探測）、Traceroute（跟蹤1個分組從源點到終點的路徑，

原理 = 從源主機向目的主機發送一連串的IP數據報）

下面，將主要介紹Ping的過程

Ping的過程

定義 Packet InterNet Groper，即 分組網間探測

是 ICMP報文的一個重要應用：使用了IPCM回送請求 & 回送回答報文

路由器與交換機的區別

Cookie

cookie 是一個非常具體的東西，指的就是瀏覽器里面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。

cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。

由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據太多磁盤空間，所以每個域的cookie數量是有限的。

Session

session 從字面上講，就是會話。

這個就類似於你和一個人交談，你怎么知道當前和你交談的是張三而不是李四呢？對方肯定有某種特征（長相等）表明他就是張三。

session 也是類似的道理，服務器要知道當前發請求給自己的是誰。

為了做這種區分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自於誰了。

至於客戶端怎么保存這個“身份標識”，可以有很多種方式，對於瀏覽器客戶端，大家都默認采用 cookie 的方式。

服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全。

可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一台服務器的時候session會丟失。

Token

在Web領域基於Token的身份驗證隨處可見。在大多數使用Web API的互聯網公司中，tokens 是多用戶下處理認證的最佳方式。

以下幾點特性會讓你在程序中使用基於Token的身份驗證

無狀態、可擴展
支持移動設備
跨程序調用
安全

那些使用基於Token的身份驗證的大佬們

大部分你見到過的API和Web應用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。

基於服務器驗證方式暴露的一些問題

Seesion：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。
可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。
CORS(跨域資源共享)：當我們需要讓數據跨多台移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。
CSRF(跨站請求偽造)：用戶在訪問銀行網站時，他們很容易受到跨站請求偽造的攻擊，並且能夠被利用其訪問其他的網站。

基於Token的驗證原理

NoSession意味着你的程序可以根據需要去增減機器，而不用去擔心用戶是否登錄。

基於Token的身份驗證的過程如下:

用戶通過用戶名和密碼發送請求。
程序驗證。
程序返回一個簽名的token 給客戶端。
客戶端儲存token,並且每次用於每次發送請求。
服務端驗證token並返回數據。

Tokens的優勢

無狀態、可擴展

基於這種無狀態和不存儲Session信息，負載負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。

如果我們將已驗證的用戶的信息保存在Session中，則每次請求都需要用戶向已驗證的服務器發送驗證信息(稱為Session親和性)。用戶量大時，可能會造成一些擁堵。

安全性

請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求偽造)。

即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用於認證。不將信息存儲在Session中，讓我們少了對session操作。

token是有時效的，一段時間之后用戶需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。

可擴展性

Tokens能夠創建與其它程序共享權限的程序。例如，能將一個隨便的社交帳號和自己的大號(Fackbook或是Twitter)聯系起來。當通過服務登錄Twitter(我們將這個過程Buffer)時，我們可以將這些Buffer附到Twitter的數據流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens時，可以提供可選的權限給第三方應用程序。當用戶想讓另一個應用程序訪問它們的數據，我們可以通過建立自己的API，得出特殊權限的tokens。