計算機網絡彙總

時間 2021-08-12

標籤 java web 算法編程跨域瀏覽器緩存安全服務器 cookie 欄目 Java 简体版

原文原文鏈接

計算機網絡體系結構

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

TCP

Transmission Control Protocol，即傳輸控制協議web

1.屬於傳輸層通訊協議算法

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

特色

創建鏈接過程（三次握手）

報文格式

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

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

爲何要三次握手

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

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

第二次握手：Client 確認了：本身發送、接收正常，對方發送、接收正常；Server 確認了：本身接收正常，對方發送正常服務器

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

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

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 說「我沒啥要說的了」，B回答「我知道了」，

2.可是 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。