當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

6 计算机网络待更新

發布時間：2024/1/8 编程问答 21 豆豆

生活随笔收集整理的這篇文章主要介紹了 6 计算机网络待更新小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

計算機網絡待更新

網絡協議分層（四層五層都要會，大概能說出來干啥的）

應用層：

應?層通過應用進程間的交互來完成特定網絡應用，不?去關?數據是如何傳輸的，應用層是?作在操作系統中的?戶態，傳輸層及以下則?作在內核態。HTTP協議，DNS域名系統(Domain Name System）將域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便的訪問互聯網。

協議：支持郵件的SMTP，FTP

數據：應用層交互的數據單元稱為報文。

傳輸層：為應用層提供數據支持，負責向兩臺主機進程之間的通信提供通用的數據傳輸服務

只有主機才有的層次

傳輸層定義了傳輸數據的協議和端口號，主要用用于數據的分段、傳輸和重組。

傳輸協議：TCP（支付寶）,UDP（抖音）。

傳輸控制協議 TCP（Transmission Control Protocol）–提供面向連接的，可靠的數據傳輸服務。

用戶數據協議 UDP（User Datagram Protocol）–提供無連接的，盡最大努力的數據傳輸服務，實時性好，傳輸效率高，（不保證數據傳輸的可靠性）。

數據單元：數據段

網絡層：提供的是主機之間的通信

不希望傳輸層協議處理太多的事情，只需要服務好應?即可，讓其作為應?間數據傳輸的媒介，幫助實現應?到應?的通信，?實際的傳輸功能就交給下?層，也就是?絡層（Internet Layer）。

網絡層的任務就是選擇合適的網間路由和交換結點，確保數據及時傳送，實現主機與主機之間的通信。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成包進行傳送。在 TCP/IP 體系結構中，由于網絡層使用 IP 協議，因此分組也叫 IP 數據報 ，簡稱 數據報。

主要是對數據包中的IP地址進行解析和封裝，這一層數據叫做數據包，工作設備是：路由器、交換機，防火墻

網絡層最常使用的是 IP 協議（Internet Protocol），IP 協議會將傳輸層的報文作為數據部分，再加上 IP 包頭組裝成 IP 報文，如果 IP 報文大小超過MTU（以太網中一般為 1500 字節）就會再次進行分片，得到一個即將發送到網絡的 IP 報文。

一個是網絡號，負責標識該 IP 地址是屬于哪個子網的；
一個是主機號，負責標識同一子網下的不同主機；

除了尋址能力， IP 協議還有另一個重要的能力就是路由。實際場景中，兩臺設備并不是用一條網線連接起來的，而是通過很多網關、路由器、交換機等眾多網絡設備連接起來的，那么就會形成很多條網絡的路徑，因此當數據包到達一個網絡節點，就需要通過算法決定下一步走哪條路徑。

所以，IP 協議的尋址作用是告訴我們去往下一個目的地該朝哪個方向走，路由則是根據「下一個目的地」選擇路徑。尋址更像在導航，路由更像在操作方向盤。

數據鏈路層：負責通過一條鏈路從一個結點向另一個物理鏈路直接相連的相鄰接點傳送數據報

主要是對數據包中的MAC地址進行解析和封裝，這一層數據叫做幀。工作設備是：網卡、網橋、交換機

MAC 的作?則是實現「直連」的兩個設備之間通信，? IP 則負責在「沒有直連」的兩個網絡之間進?通信傳輸。

源IP地址和目標IP地址在傳輸過程中是不會變化的，只有源 MAC 地址和目標MAC ?直在變化。

每?臺設備的網卡都會有?個 MAC 地址，它就是?來唯?標識設備的。路由器計算出了下?個目的地 IP 地址，再通過 ARP 協議找到該目的地的 MAC 地址，這樣就知道這個 IP 地址是哪個設備的了。

物理層：

在物理層上所傳送的數據單位是比特。

物理層(physical layer)的作用是實現相鄰計算機節點之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質和物理設備的差異， 使其上面的數據鏈路層不必考慮網絡的具體傳輸介質是什么。

HTTP常見概念

HTTP報文結構

1.請求行

2.請求頭

3.空行

4.消息主體
HTTP報文結構

HTTP 基本概念

HTTP 是?個在計算機世界?專?在「兩點」之間「傳輸」?字、圖?、?頻、視頻等「超?本」數據的「約定和規范」。

常見的狀態碼（實在記不住先記著五大類的）

1xx：表示接收的請求正在處理

2xx （3種）：表示服務器成功處理了客戶端請求

200 OK：表示接收請求正常處理完畢并且返回，且響應頭會有body數據；

204 No Content：表示客戶端發送給客戶端的請求得到了成功處理，但在響應頭沒有body數據；

206 Patial Content：表示響應返回的 body 數據并不是資源的全部。

3xx （5種）：客戶端請求的資源發生了變動，需要客戶端用新的URL重新發送請求獲取資源，也就是重定向

301 Moved Permanently：永久性重定向，表示請求的資源已經不存在，需要改用新的URL再次訪問；

302 Found：臨時性重定向，表示請求的資源被還在，但是需要使用新的URL來訪問；

301與302的區別：前者是永久移動，后者是臨時移動（之后可能還會更改URL），301和302都會在響應頭里面使用字段location，指明后續需要跳轉的URL，瀏覽器會自動重定向新的URL

4xx （4種）：表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義。

401Unauthorized 未授權需要用戶提供賬戶和密碼

403 Forbidden：表示服務器禁?訪問資源，并不是客戶端的請求出錯；跨域，或者路徑寫錯

404 Not Found：表示服務器上無法找到請求的資源；

5xx （2種）：表示客戶端請求報文正確，但是服務器內部發生了錯誤，屬于服務器端的錯誤碼

501 Not Implemented」表示客戶端請求的功能還不?持，類似“即將開業，敬請期待”的意思。
502bad gateway

503 Server Unavailable：表示服務器當前很忙，暫時?法響應服務器，

Get 與 Post

Get ?法的含義是請求從服務器獲取資源，這個資源可以是靜態的?本、??、圖?視頻等。（比如看文章）

POST它向 URI(Universal Resource Identifier, 通用的資源標志符) 指定的資源提交數據，數據就放在報?的 body ?。（比如留言）

是否為安全和冪等：先說明下安全和冪等的概念：
在 HTTP 協議?，所謂的「安全」是指請求?法不會「破壞」服務器上的資源。

所謂的「冪等」，意思是多次執?相同的操作，結果都是「相同」的。
那么很明顯 GET ?法就是安全且冪等的，因為它是「只讀」操作，?論操作多少次，服務器上的數據都是安全的，且每次的結果都是相同的。
POST 因為是「新增或提交數據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數據就會創建多個資源，所以不是冪等的

HTTP 特性

優點：簡單，靈活和容易拓展，應用廣泛和跨平臺

缺點：無狀態（同一個客戶第二次訪問跟第一次訪問沒區別），明文傳輸，不安全（通信使用明文，內容可能被竊聽；不驗證通信方的身份，因此可能遭遇偽裝；無法驗證報文完整性，有可能已經遭篡改）；

解決方案：用HTTPS的方式解決，引入SSL/TLS層

HTTPS 與 HTTP

TSL是運行在傳輸層之上的協議。

區別：

HTTP 是超?本傳輸協議，信息是明?傳輸，存在安全?險的問題。 HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ?絡層之間加?了SSL/TLS 安全協議，使得報?能夠加密傳輸。

HTTP 連接建?相對簡單， TCP 三次握?之后便可進? HTTP 的報?傳輸。? HTTPS 在 TCP 三次握?之后，還需進? SSL/TLS 的握?過程，才可進?加密報?傳輸。

HTTP 的端?號是 80， HTTPS 的端?號是 443。

HTTPS 協議需要向 CA（證書權威機構, Certificate Authority）申請數字證書，來保證服務器的身份是可信的。

HTTPS 解決了 HTTP 的哪些問題？

HTTP 由于是明?傳輸，所以安全上存在以下三個?險：
竊聽?險，?如通信鏈路上可以獲取通信內容，?戶號容易沒。
篡改?險，?如強制植?垃圾?告，視覺污染，?戶眼容易瞎。
冒充?險，?如冒充淘寶?站，?戶錢容易沒

HTTPS 在 HTTP 與 TCP 層之間加?了 SSL/TLS 協議，可以很好的解決了上述的?險：
信息加密：交互信息?法被竊取，但你的號會因為「?身忘記」賬號?沒。
校驗機制：?法篡改通信內容，篡改了就不能正常顯示，但百度「競價排名」依然可以搜索垃圾?告。
身份證書：證明淘寶是真的淘寶?，但你的錢還是會因為「剁?」?沒

HTTPS 是如何解決上?的三個?險的

混合加密的?式實現信息的機密性，解決了竊聽的?險。

摘要算法的?式來實現完整性，它能夠為數據?成獨???的「指紋」，指紋?于校驗數據的完整性，解決了篡改的?險。

將服務器公鑰放?到數字證書中，解決了冒充的?險。

混合加密：用來信息加密

HTTPS 采?的是對稱加密和?對稱加密結合的「混合加密」?式：
在通信建?前采??對稱加密的?式交換「會話秘鑰」，后續就不再使??對稱加密。
在通信過程中全部使?對稱加密的「會話秘鑰」的?式加密明?數據。
采?「混合加密」的?式的原因：
對稱加密只使??個密鑰，運算速度快，密鑰必須保密，?法做到安全的密鑰交換。
?對稱加密使?兩個密鑰：公鑰和私鑰，公鑰可以任意分發?私鑰保密，解決了密鑰交換問題但速度慢。

摘要算法：校驗數據完整性，解決篡改風險

摘要算法?來實現完整性，能夠為數據?成獨???的「指紋」，?于校驗數據的完整性，解決了篡改的?險。

客戶端在發送明?之前會通過摘要算法算出明?的「指紋」，發送的時候把「指紋 + 明?」?同加密成密?后，發送給服務器，服務器解密后，?相同的摘要算法算出發送過來的明?，通過?較客戶端攜帶的「指紋」和當前算出的「指紋」做?較，若「指紋」相同，說明數據是完整的

數字證書

客戶端先向服務器端索要公鑰，然后?公鑰加密信息，服務器收到密?后，???的私鑰解密。
這就存在些問題，如何保證公鑰不被篡改和信任度？
所以這?就需要借助第三?權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的

關于非對稱加密，數字證書，公鑰和私鑰、RSA

秘鑰分類：

對稱密鑰加密（沒有私鑰公鑰的概念），又稱私鑰加密或會話密鑰加密算法，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。它的最大優勢是加/解密速度快，適合于對大數據量進行加密，但密鑰管理困難。私人的，不會公開。

非對稱密鑰加密系統（一個公開，一個是私人的，因為是公開的也稱為公鑰系統），又稱公鑰密鑰加密。它需要使用不同的密鑰來分別完成加密和解密操作，一個公開發布，即公開密鑰，另一個由用戶自己秘密保存，即私用密鑰。信息發送者用公開密鑰去加密，而信息接收者則用私用密鑰去解密。公鑰機制靈活，但加密和解密速度卻比對稱密鑰加密慢得多。

非對稱加密才可以實現機密性和認證性。
v從

非對稱加密

數字證書原理、能否自己發布、怎么驗證？

公鑰和私鑰

RSA

對稱加密算法和非對稱加密算法

對稱加密算法：DES、AES
非對稱加密：RSA,DSA

HTTP/1.1、 HTTP/2、 HTTP/3 演變（3不看）

說說 HTTP/1.1 相? HTTP/1.0 提?了什么性能？

HTTP/1.0 默認使用的是短連接，每次請求都要重新建立一次連接。且HTTP是基于TCP/IP協議的，每次建立或者斷開連接都要三次握手四次揮手的開銷，這樣開銷比較大。

HTTP/1.1 相? HTTP/1.0 性能上的改進：

使? TCP ?連接的?式改善了 HTTP/1.0 短連接造成的性能開銷。能維持一個長連接，可以用多個長鏈接的方式發送多個請求，
?持管道（pipeline）網絡傳輸，只要第?個請求發出去了，不必等其回來，就可以發第?個請求出去，可以減少整體的響應時間。（但是服務器還是按照順序，先回應A請求，再回應B請求，前面的回應如果很慢，后面的很多請求排隊等著，這就是隊頭阻塞）。

但 HTTP/1.1 還是有性能瓶頸：

請求 / 響應頭部（Header）未經壓縮就發送，?部信息越多延遲越?。只能壓縮 Body 的部分；
發送冗?的?部。每次互相發送相同的?部造成的浪費較多；
服務器是按請求的順序響應的，如果服務器響應慢，會招致客戶端?直請求不到數據，也就是隊頭阻塞；
沒有請求優先級控制；
請求只能從客戶端開始，服務器只能被動響應

HTTP/2 相? HTTP/1.1 性能上的改進：

HTTP/2 協議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

1.頭部壓縮

HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是?樣的或是相似的，那么，協議會幫你消除重復的部分。這就是所謂的 HPACK 算法：在客戶端和服務器同時維護?張頭信息表，所有字段都會存?這個表，?成?個索引號，以后就不發送同樣字段了，只發送索引號，這樣就提?速度了。

2.二進制格式
HTTP/2 不再像 HTTP/1.1 ?的純?本形式的報?，?是全?采?了?進制格式，增加了數據傳輸的效率

3.數據流
HTTP/2 的數據包不是按順序發送的，同?個連接??連續的數據包，可能屬于不同的回應。因此，必須要對數據包做標記，指出它屬于哪個回應。

數據流有獨一無二的編號，用來標記，指出自己是屬于哪一個回應。客戶端還可以指定數據流的優先級，這樣服務器就可以優先響應該請求。

4.多路復用

在?個連接中并發多個請求或回應，?不?按照順序??對應，也就不會再出現「隊頭阻塞」問題，降低了延遲，?幅度提?了連接的利?率。

HTTP/2 有哪些缺陷？ HTTP/3 做了哪些優化

HTTP/2 主要的問題在于，多個 HTTP 請求在復??個 TCP 連接，下層的 TCP 協議是不知道有多少個 HTTP 請求的。所以?旦發?了丟包現象，就會觸發 TCP 的重傳機制，這樣在?個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來。

HTTP/1.1 中的管道（ pipeline）傳輸中如果有?個請求阻塞了，那么隊列后請求也統統被阻塞住了
HTTP/2 多個請求復??個TCP連接，?旦發?丟包，就會阻塞住所有的 HTTP 請求。

這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP！

UDP 發?是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞和 HTTP/2 的?個丟包全部重傳問題。
?家都知道 UDP 是不可靠傳輸的，但基于 UDP 的 QUIC （Quick UDP Internet Connections）協議可以實現類似 TCP 的可靠性傳輸。

HTTP/1.1優化思路

第?個思路是，通過緩存技術來避免發送 HTTP 請求。客戶端收到第?個請求的響應后，可以將其緩存在本地磁盤，下次請求的時候，如果緩存沒過期，就直接讀取本地緩存的響應數據。如果緩存過期，客戶端發送請求的時候帶上響應數據的摘要，服務器?對后發現資源沒有變化，就發出不帶包體的 304 響應，告訴客戶端緩存的響應仍然有效。
第?個思路是，減少 HTTP 請求的次數，有以下的?法：

將原本由客戶端處理的重定向請求，交給代理服務器處理，這樣可以減少重定向請求的次數；

將多個?資源合并成?個?資源再傳輸，能夠減少 HTTP 請求次數以及頭部的重復傳輸，再來減少 TCP 連接數量，進?省去 TCP 握?和慢啟動的?絡消耗；

按需訪問資源，只訪問當前?戶看得到/?得到的資源，當客戶往下滑動，再訪問接下來的資源，以此達到延遲請求，也就減少了同?時間的 HTTP 請求次數。

第三思路是，通過壓縮響應資源，降低傳輸資源的??，從?提?傳輸效率，所以應當選擇更優秀的壓縮算法。

TCP 和 UDP 區別

TCP 是?向連接的、可靠的、基于字節流的傳輸層通信協議。

1.連接
TCP 是?向連接的傳輸層協議，傳輸數據前先要建?連接。
UDP 是不需要連接，即刻傳輸數據。

2.服務對象
TCP 是?對?的兩點服務，即?條連接只有兩個端點。
UDP ?持?對?、?對多、多對多的交互通信

3.可靠性
TCP 是可靠交付數據的，數據可以?差錯、不丟失、不重復、按需到達。
UDP 是盡最?努?交付，不保證可靠交付數據。

4.擁塞控制、流量控制
TCP 有擁塞控制和流量控制機制，保證數據傳輸的安全性。
UDP 則沒有，即使?絡?常擁堵了，也不會影響 UDP 的發送速率。

5.?部開銷
TCP ?部長度較長，會有?定的開銷，?部在沒有使?「選項」字段時是 20 個字節，如果使?了「選項」字段則會變?的。
UDP ?部只有 8 個字節，并且是固定不變的，開銷較?。

6.傳輸?式
TCP 是流式傳輸，但保證順序和可靠。
UDP 是?個包?個包的發送，是有邊界的，但可能會丟包和亂序。
TCP 和 UDP 應?場景：
由于 TCP 是?向連接，能保證數據的可靠性交付，因此經常?于：
FTP ?件傳輸（File Transfer Protocol，FTP）
HTTP / HTTPS
由于 UDP ?向?連接，它可以隨時發送數據，再加上UDP本身的處理既簡單??效，因此經常?于：
包總量較少的通信，如 DNS 、 SNMP 等、視頻、?頻等多媒體通信、?播通信

TCP流式和UDP包

按層次分， TCP 位于傳輸層，提供可靠的字節流服務。所謂的字節流服務（Byte Stream Service）是指，為了方便傳輸，將大塊數據分割成以報文段（segment）為單位的數據包進行管理。

為什么說UDP是面向報文的，而TCP是面向字節流的？

UDP是面向報文的：發送方的UDP對應用程序交下來的報文，在添加了首部之后就向下交付，UDP對應用層交付下來的報文即不合并也不拆分，而是保留這些報文的邊界，應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文，接收方UDP對下方交上來的UDP用戶數據報，在去除首部之后就原封不動的交付給上層的應用程序，一次交付一個完整報文，所以是UDP是面向報文的

TCP是面向字節的：發送方TCP對應用程序交下來的報文數據塊，視為無結構的字節流（無邊界約束，可拆分/合并），但維持各字節流順序（相對順序沒有變），TCP發送方有一個發送緩沖區，當應用程序傳輸的數據塊太長，TCP就可以把它劃分端一些再傳輸，如果應用程序一次只傳輸一個字節，那么TCP可以等待積累足夠多的字節后再構成報文端發送出去，所以TCP的面向字節的

TCP報文段

6個控制位，一個占一位。

序列號 seq： 在建?連接時由計算機?成的隨機數作為其初始值，通過 SYN 包傳給接收端主機，每發送?次數據，就「累加」?次該「數據字節數」的??。 ?來解決?絡包亂序問題。
確認應答號 ack： 指下?次「期望」收到的數據的序列號，發送端收到這個確認應答以后可以認為在這個序號以前的數據都已經被正常接收。 ?來解決不丟包的問題。

HTTPS通信(先不看)

概念

HTTPS 并非是應用層的一種新協議。只是 HTTP 通信接口部分用
SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代
替而已。
HTTPS通信會先進行TCP三次握手，再進行TLS三次握手，之后再進行通信內容。

主要干了什么

商定雙方通信所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等)；
確定雙方所要使用的密碼組合；
客戶端通過服務器的公鑰和數字證書 (上篇文章已有介紹)上的數字簽名驗證服務端的身份；
生成會話密鑰，該密鑰將用于握手結束后的對稱加密。

TLS詳細過程(先不看)

下面來看 TLS 握手的詳細過程 (注：此圖與HTTPS詳解一中的 HTTPS 原理圖的流程大致相同，不同的是此圖把重點放在了TLS握手的相關概念上)：

根據小林的東西整理得到以下過程：
1、第一次握手：客戶端?先會發?個「Client Hello」消息，以及?成的隨機數（Client Random），這個隨機數會被服務端保留，它是?成對稱加密密鑰的材料之?。
2、TLS 第?次握?
服務端收到信息后，返回信息，也會給出一個隨機數（Server Random），密碼套件里面會有密鑰交換算法 +簽名算法 + 對稱加密算法 + 摘要算法

通過上面兩次握手，客戶端和服務端就已確認了 TLS 版本和使?的密碼套件
服務端為了證明??的身份，會發送「Server Certificate」給客戶端，這個消息?含有數字證書。
3、三次握手
客戶端驗證完證書后，認為可信則繼續往下?。接著，客戶端就會?成?個新的隨機數 (pre-master)，?服務器的 RSA 公鑰加密該隨機數，然后把消息傳遞給服務端。
此時客戶端和服務端雙?都共享了三個隨機數，分別是 Client Random、 Server Random、 pre-master。

于是，雙?根據已經得到的三個隨機數，?成會話密鑰（Master Secret），它是對稱密鑰，?于對后續的 HTTP請求/響應的數據加解密。

客戶端發送一個用生成的繪話秘鑰加密的消息，發送給服務端，讓服務端做個驗證

4、四次握手
也是同樣操作，如果雙方的驗證加密解密都沒有什么問題，握手就正式完成。

TCP三次握手，和四次揮手

只有在請求連接和請求連接的接受才會有SYN=1, 其他都是0

四次揮手中，

從上?的過程可以發現第三次握?是可以攜帶數據的，前兩次握?是不可以攜帶數據的，這也是?試常問的題

?旦完成三次握?，雙?都處于 ESTABLISHED 狀態，此時連接就已建?完成，客戶端和服務端就可以相互發送數據了。

你可以看到，每個?向都需要?個 FIN 和?個 ACK，因此通常被稱為四次揮?

這??點需要注意是：主動關閉連接的，才有 TIME_WAIT 狀態

為什么要三次握手

TCP頭部格式含義：

序列號：用來解決網絡包亂序問題。

確認應答號：用來解決不丟包的問題。

控制位：
ACK：該位為 1 時，「確認應答」的字段變為有效， TCP 規定除了最初建?連接時的 SYN 包之外該位必須設置為 1 。
RST：該位為 1 時，表示 TCP 連接中出現異常必須強制斷開連接。
SYN：該位為 1 時，表示希望建?連接，并在其「序列號」的字段進?序列號初始值的設定。
FIN：該位為 1 時，表示今后不會再有數據發送，希望斷開連接。當通信結束希望斷開連接時，通信雙?的主機之間就可以相互交換 FIN 位為 1 的 TCP 段。

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

1.三次握手才可以防止歷史重復連接的初始化（主要原因）：

客戶端連續發送多次 SYN 建?連接的報?，在網絡擁堵情況下：?個「舊 SYN 報?」?「最新的 SYN 」報?早到達了服務端；那么此時服務端就會回?個 SYN + ACK 報?給客戶端；客戶端收到后可以根據?身的上下?，判斷這是?個歷史連接（序列號過期或超時），那么客戶端就會發送RST 報?給服務端，表示中?這?次連接。

如果是兩次握?連接，就不能判斷當前連接是否是歷史連接，三次握?則可以在客戶端（發送?）準備發送第三次報?時，客戶端因有?夠的上下?來判斷當前連接是否是歷史連接：如果是歷史連接（序列號過期或超時），則第三次握?發送的報?是 RST 報?，以此中?歷史連接；如果不是歷史連接，第三次發送的報文就是ACK報文，通信雙方就會成功建立連接。

2.三次握?才可以同步雙?的初始序列號

TCP 協議的通信雙?，都必須維護?個「序列號」，序列號是可靠傳輸的?個關鍵因素，它的作?：

接收?可以去除重復的數據；
接收?可以根據數據包的序列號按序接收；
可以標識發送出去的數據包中，哪些是已經被對?收到的；

可?，序列號在 TCP 連接中占據著?常重要的作?，所以當客戶端發送攜帶「初始序列號」的 SYN 報?的時候，需要服務端回?個 ACK 應答報?，表示客戶端的 SYN 報?已被服務端成功接收，那當服務端發送「初始序列號」給客戶端的時候，依然也要得到客戶端的應答回應，這樣?來?回，才能確保雙?的初始序列號能被可靠的同步。

兩次握?只保證了??的初始序列號能被對?成功接收，沒辦法保證雙?的初始序列號都能被確認接收。

3.三次握?才可以避免資源浪費

假如兩次就可以建立連接，當客戶端的SYN請求連接在網絡中阻塞時，由于阻塞，服務器也不會去發ACK報文，超時后，客戶端又會繼續發送SYN請求連接，服務器不清楚客戶端是否收到了??發送的建?連接的 ACK 確認信號，所以每收到一個SYN就會主動建立一個連接。這樣就會建立多個冗余無效連接，造成很大的資源浪費。

總結：

TCP 建?連接時，通過三次握?能防?歷史連接的建?，能減少雙?不必要的資源開銷，能幫助雙?同步初始化序列號。序列號能夠保證數據包不重復、不丟棄和按序傳輸。
不使?「兩次握?」和「四次握?」的原因：
「兩次握?」：?法防?歷史連接的建?，會造成雙?資源的浪費，也?法可靠的同步雙?序列號；
「四次握?」：三次握?就已經理論上最少可靠連接建?，所以不需要使?更多的通信次數。

為什么揮?需要四次

再來回顧下四次揮?雙?發 FIN 包的過程，就能理解為什么需要四次了。
關閉連接時，客戶端向服務端發送 FIN 時，僅僅表示客戶端不再發送數據了但是還能接收數據。
服務器收到客戶端的 FIN 報?時，先回?個 ACK 應答報?，?服務端可能還有數據需要處理和發送，等服務端不再發送數據時，才發送 FIN 報?給客戶端來表示同意現在關閉連接。

從上?過程可知，服務端通常需要等待完成數據的發送和處理，所以服務端的 ACK 和 FIN ?般都會分開發送，從??三次握?導致多了?次。

為什么 TIME_WAIT 等待的時間是 2MSL？

MSL 是 Maximum Segment Lifetime，報?最??存時間；

客戶端給服務端發的ACK報文段后，如果沒有到達，此時服務器會重新傳送第三次的FIN+ACK報文段，A就會在2MSL時間內收到服務端重傳的報文段，A會重傳一次確認，然后計時器重啟；如果沒有等待這個時間，服務端一直收不到最后一次ACK，他就會一直發送第三次的報文段，這樣服務端就無法關閉。
記住：此時客戶端的狀態時TIME-WAIT，服務端的狀態是 LAST-ACK。

為什么需要 TIME_WAIT 狀態？’

TCP連接的優化，根據圖解網絡中的TCP內核參數寫的(先不看)

三次握手性能提升

四次揮手性能提升

TCP傳輸數據的性能提升

TCP 協議如何保證可靠傳輸

應用數據被分割成 TCP 認為最適合發送的數據塊。

TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。

校驗和： TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。

TCP 的接收端會丟棄重復的數據。

流量控制： TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發送端發送接收端緩沖區能接納的數據。當接收方來不及處理發送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP使用的流量控制協議是可變大小的滑動窗口協議。（TCP 利用滑動窗口實現流量控制）

擁塞控制：當網絡擁塞時，減少數據的發送。

ARQ協議：也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認后再發下一個分組。

超時重傳：當 TCP 發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

ARQ協議

自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送后一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

停止等待ARQ協議自動重傳請求（Automatic Repeat-reQuest，ARQ）

停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認（回復ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發送成功，需要重新發送，直到收到確認后再發下一個分組；
在停止等待協議中，若接收方收到重復分組，就丟棄該分組，但同時還要發送確認；
優點：簡單

缺點：信道利用率低，等待時間長

無差錯情況:

發送方發送分組,接收方在規定時間內收到,并且回復確認.發送方再次發送。

出現差錯情況（超時重傳）:

停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送過的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ 。另外在停止等待協議中若收到重復分組，就丟棄該分組，但同時還要發送確認。連續 ARQ 協議可提高信道利用率。發送維持一個發送窗口，凡位于發送窗口內的分組可連續發送出去，而不需要等待對方確認。接收方一般采用累積確認，對按序到達的最后一個分組發送確認，表明到這個分組位置的所有分組都已經正確收到了。

確認丟失和確認遲到

確認丟失：確認消息在傳輸過程丟失。當A發送M1消息，B收到后，B向A發送了一個M1確認消息，但卻在傳輸過程中丟失。而A并不知道，在超時計時過后，A重傳M1消息，B再次收到該消息后采取以下兩點措施：1. 丟棄這個重復的M1消息，不向上層交付。 2. 向A發送確認消息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的確認消息丟失）。
確認遲到：確認消息在傳輸過程中遲到。A發送M1消息，B收到并發送確認。在超時時間內沒有收到確認消息，A重傳M1消息，B仍然收到并繼續發送確認消息（B收到了2份M1）。此時A收到了B第二次發送的確認消息。接著發送其他數據。過了一會，A收到了B第一次發送的對M1的確認消息（A也收到了2份確認消息）。處理如下：1. A收到重復的確認后，直接丟棄。2. B收到重復的M1后，也直接丟棄重復的M1。
連續ARQ協議
連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位于發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。

優點：信道利用率高，容易實現，即使確認丟失，也不必重傳。

缺點：不能向發送方反映出接收方已經正確收到的所有分組的信息。比如：發送方發送了 5條消息，中間第三條丟失（3號），這時接收方只能對前兩個發送確認。發送方無法知道后三個分組的下落，而只好把后三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。

連續ARQ協議

連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位于發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。

優點：信道利用率高，容易實現，即使確認丟失，也不必重傳。

Socket 通信具體原理 (先不看)

https://blog.csdn.net/qq_28865297/article/details/71123832

TCP重傳

所以 TCP 針對數據包丟失的情況，會?重傳機制解決。

接下來說說常?的重傳機制：

超時重傳：

就是在發送數據時，設定?個定時器，當超過指定的時間后，沒有收到對?的 ACK確認應答報?，就會重發該數據，也就是我們常說的超時重傳。

TCP 會在以下兩種情況發?超時重傳：
1.數據包丟失
2.確認應答丟失

快速重傳（數據驅動，三次ACK）

它不以時間為驅動，?是以數據驅動重傳。

快速重傳的?作?式是當收到三個相同的 ACK 報?時，會在定時器過期之前，重傳丟失的報?段。

問題：?如對于上?的例?，是重傳 Seq2 呢？還是重傳 Seq2、 Seq3、 Seq4、 Seq5 呢？因為發送端并不清楚這連續的三個 Ack 2 是誰傳回來的。
根據 TCP 不同的實現，以上兩種情況都是有可能的。可?，這是?把雙刃劍。
為了解決不知道該重傳哪些 TCP 報?，于是就有 SACK ?法。

SACK（ Selective Acknowledgment 選擇性確認）

這種方式需要在 TCP 頭部「選項」字段?加?個 SACK 的東?，它可以將緩存的地圖發送給發送?，這樣發送?就可以知道哪些數據收到了，哪些數據沒收到，知道了這些信息，就可以只重傳丟失的數據。

D-SACK （Duplicate SACK ）

主要使?了 SACK 來告訴「發送?」有哪些數據被重復接收了。

滑動窗口

我們都知道 TCP 是每發送?個數據，都要進??次確認應答。當上?個數據包收到了應答了，再發送下?個。但這種?式的缺點是效率?較低的。數據包的往返時間越長，通信的效率就越低。而且數據包往返時間越長，通信效率越低。

為解決這個問題， TCP 引?了窗?這個概念。即使在往返時間較?的情況下，它也不會降低?絡通信的效率

窗口大小就是指?需等待確認應答，?可以繼續發送數據的最?值；窗?的實現實際上是操作系統開辟的?個緩存空間，發送?主機在等到確認應答返回之前，必須在緩沖區中保留已發送的數據。如果按期收到確認應答，此時數據就可以從緩存區清除。

問題：窗???由哪??決定

TCP 頭?有?個字段叫 Window ，也就是窗???。
這個字段是接收端告訴發送端??還有多少緩沖區可以接收數據。于是發送端就可以根據這個接收端的處理能?來發送數據，?不會導致接收端處理不過來。
所以，通常窗?的??是由接收?的窗???來決定的。

接收窗?和發送窗?的??是相等的嗎？

并不是完全相等，接收窗?的??是約等于發送窗?的??的。

知道一件事情

發送窗口的大小是根據min(cwnd, awnd)一個是擁塞窗口大小，一個是通知窗口大小，通知窗口大小awnd，TCP通過和接收端交換一個數據包就可以獲取。但是cwnd怎么獲取呢？獲取最佳值的唯一辦法就是用越來越快的速率不斷發送數據，直到數據包丟失或者網絡擁塞為止。其實就是下面的擁塞控制的幾種方式。

流量控制

發送?不能?腦的發數據給接收?，要考慮接收?處理能? 。如果?直?腦的發數據給對?，但對?處理不過來，那么就會導致觸發重發機制，從而導致網絡流量的無端的浪費。為了解決這種現象發?， TCP 提供?種機制可以讓「發送?」根據「接收?」的實際接收能?控制發送的數據量，這就是所謂的流量控制。

擁塞控制

總過程：
方式一： 慢啟動->擁塞避免階段->擁塞發生（超時重傳,ssthresh變成cwnd / 2, cwnd重置為1）-> 重新進入慢啟動，擁塞避免
方式二： 慢啟動->擁塞避免階段->擁塞發生（快速重傳，說明網絡情況不是特別差，cwnd= cwnd/ 2, ssthresh=cwnd）->進入快速恢復（cwnd -> ssthresh + 3,如果收到重復的ACK信號，cwnd + 1, 如果收到新的ack，說明重復的ACK數據都已經收到，恢復過程已經結束，可以回到恢復之前的狀態，也就是再次進入擁塞避免）

前?的流量控制是避免「發送?」的數據填滿「接收?」的緩存，但是并不知道?絡的中發?了什么。

?般來說，計算機?絡都處在?個共享的環境。因此也有可能會因為其他主機之間的通信使得?絡擁堵。

在?絡出現擁堵時，如果繼續發送?量數據包，可能會導致數據包時延、丟失等，這時 TCP 就會重傳數據，但是?重傳就會導致?絡的負擔更重，于是會導致更?的延遲以及更多的丟包，這個情況就會進?惡性循環被不斷地放?

于是，就有了擁塞控制，控制的?的就是避免「發送?」的數據填滿整個?絡。為了在「發送?」調節所要發送數據的量，定義了?個叫做「擁塞窗?」的概念。

發送窗口：swnd

接收窗口：awnd：接收方根據接收緩存設置的值，并告知發送方，反映接收方容量。

擁塞窗口：cwnd：發送方根據自己估算的網絡擁塞程度而設置的窗口值，反映網絡當前容量。

擁塞窗? cwnd是發送?維護的?個的狀態變量，它會根據?絡的擁塞程度動態變化的。

擁塞窗? cwnd 變化的規則：
只要?絡中沒有出現擁塞， cwnd 就會增?；
但?絡中出現了擁塞， cwnd 就減少

那么怎么知道當前?絡是否出現了擁塞呢？

其實只要「發送?」沒有在規定時間內接收到 ACK 應答報?，也就是發?了超時重傳，就會認為?絡出現了?擁塞。

擁塞控制主要是四個算法：

慢啟動

?點?點的提?發送數據包的數量，當發送?每收到?個 ACK，擁塞窗? cwnd 的??就會加 1

擁塞避免

超過慢啟動門限后，就會進入擁塞避免算法。

每當收到?個 ACK 時， cwnd 增加 1/cwnd。擁塞避免算法就是將原本慢啟動算法的指數增長變成了線性增長

增長到某一個階段，網絡就會慢慢進入擁塞狀況，就會出現丟包現象，就需要對丟失的數據包進行重傳。出發了重傳機制后，也就進入了擁塞發生算法。

擁塞發?

當?絡出現擁塞，也就是會發?數據包重傳，重傳機制主要有兩種：
超時重傳
快速重傳
這兩種使?的擁塞發送算法是不同的，接下來分別來說說。

如果是超時重傳

此時：初始慢啟動門限設置為cwnd / 2;(當前擁塞窗口的一半)，

cwnd重置為1，接著重新開始慢啟動（馬上回到解放前），這種方式比較激進，反應也很強烈，會造成網絡卡頓。

如果TCP重傳機制是快速重傳

TCP會認為網絡沒那么糟糕，認為大部分沒有丟，只是丟了一小部分。

ssthresh 和 cwnd 變化如下：
cwnd = cwnd/2 ，也就是設置為原來的?半;
ssthresh = cwnd ;
進?快速恢復算法

快速恢復

快速恢復算法是認為，你還能收到 3 個重復 ACK 說明?絡也不那么糟糕，所以沒有必要像 RTO 超時那么強烈。進入快速恢復以前，cwnd和ssthresh已經被更新了：

cwnd = cwnd/2 ，也就是設置為原來的?半;
ssthresh = cwnd ;

然后，進入到快速恢復算法如下：

擁塞窗口 cwnd = ssthresh + 3（ 3 的意思是確認有 3 個數據包被收到了）；

重傳丟失的數據包

如果再收到重復的 ACK，那么 cwnd 增加 1；

如果收到新數據的ACK后，可以把cwnd設置為第一步中的ssthresh值，因為ACK確認了新的值，說明從duplicated ACK時的數據都已經收到，恢復過程已經結束，可以恢復到之前的狀態，再次進入擁塞避免狀態

擁塞算法總示意圖

IP基礎知識(先不看)

?分類地址 CIDR(先不看)

32 ?特的 IP 地址被劃分為兩部分，前?是?絡號，后?是主機號。

表示形式 a.b.c.d/x ，其中 /x 表示前 x 位屬于?絡號， x 的范圍是 0 ~ 32 ，這就使得 IP 地址更加具有靈活性。

掩碼作用：

在上?我們知道可以通過??掩碼劃分出?絡號和主機號，那實際上??掩碼還有?個作?，那就是劃分??。
??劃分實際上是將主機地址分為兩個部分：???絡地址和??主機地址。形式如下：

假設對 C 類地址進???劃分，?絡地址 192.168.1.0，使???掩碼 255.255.255.192 對其進???劃分。C 類地址中前 24 位是?絡號，最后 8 位是主機號，根據??掩碼可知從 8 位主機號中借? 2 位作為??號。

子網掩碼：網絡號和子網號都為1，主機號為0；

IP協議相關技術

DNS域名解析

通常使?的?式是域名，?不是 IP 地址，因為域名?便?類記憶，DNS 域名解析，將域名?址?動轉換為具體的 IP 地址。

域名的層級關系：

DNS 中的域名都是?句點來分隔的，?如 www.server.com ，這?的句點代表了不同層次之間的界限。

根域是在最頂層，它的下?層就是 com 頂級域，再下?是 server.com。

域名的層級關系類似一個樹狀結構：

根DNS服務器
頂級域DNS服務器（com）
權威DNS服務器（server.com)

域名解析的?作流程

瀏覽器?先看?下??的緩存?有沒有，如果沒有就向操作系統的緩存要，還沒有就檢查本機域名解析?件hosts ，如果還是沒有，就會 DNS 服務器進?查詢，查詢的過程如下：

客戶端?先會發出?個 DNS 請求，問 www.server.com 的 IP 是啥，并發給本地 DNS 服務器（也就是客戶端的 TCP/IP 設置中填寫的 DNS 服務器地址）。

本地域名服務器收到客戶端的請求后，如果緩存?的表格能找到 www.server.com，則它直接返回 IP 地址。如果沒有，本地 DNS 會去問它的根域名服務器： “??，能告訴我 www.server.com 的 IP 地址嗎？ ” 根域名服務器是最?層次的，它不直接?于域名解析，但能指明?條道路。

根 DNS 收到來?本地 DNS 的請求后，發現后置是 .com，說： “www.server.com 這個域名歸 .com 區域管理”，我給你 .com 頂級域名服務器地址給你，你去問問它吧。 ”

本地 DNS 收到頂級域名服務器的地址后，發起請求問“??，你能告訴我 www.server.com 的 IP 地址嗎？ ”

頂級域名服務器說： “我給你負責 www.server.com 區域的權威 DNS 服務器的地址，你去問它應該能問到”。

本地 DNS 于是轉向問權威 DNS 服務器： “?三， www.server.com對應的IP是啥呀？ ” server.com 的權威DNS 服務器，它是域名解析結果的原出處。為啥叫權威呢？就是我的域名我做主。

子網掩碼練習網絡號 = 子網掩碼AND IP地址

什么是ARP協議 (Address Resolution Protocol)（網絡層）

ARP協議完成了IP地址與物理地址的映射。每一個主機都設有一個 ARP 高速緩存，里面有所在的局域網上的各主機和路由器的 IP 地址到硬件地址的映射表。當源主機要發送數據包到目的主機時，會先檢查自己的ARP高速緩存中有沒有目的主機的MAC地址，如果有，就直接將數據包發到這個MAC地址，如果沒有，就向所在的局域網發起一個ARP請求的廣播包（在發送自己的 ARP 請求時，同時會帶上想知道的MAC地址的主機IP地址），收到請求的主機檢查自己的IP地址是否和ARP請求包中的目標IP是否一致，如果一致就把自己的MAC地址塞入ARP響應包返回給主機。然后源主機收到響應包后，添加目的主機的IP地址和MAC地址的映射，在進行數據傳送。

什么是NAT (Network Address Translation, 網絡地址轉換)？

用于解決內網中的主機要和因特網上的主機通信。由NAT路由器將主機的本地IP地址轉換為全球IP地址，分為靜態轉換（轉換得到的全球IP地址固定不變）和動態NAT轉換。

HTTP是不保存狀態的協議,如何保存用戶狀態?

常見的有以下兩種解決方案：

基于Session實現的會話保持

在會話開始時（客戶端第一次像服務器發送http請求），服務器將會話狀態保存起來（本機內存或數據庫中），然后分配一個會話標識（SessionId）給客戶端，這個會話標識一般保存在客戶端Cookie中，以后每次瀏覽器發送http請求都會帶上Cookie中的SessionId到服務器，服務器拿到會話標識就可以把之前存儲在服務器端的狀態信息與會話聯系起來，實現會話保持（如果遇到瀏覽器禁用Cookie的情況，則可以通過url重寫的方式將會話標識放在url的參數里，也可實現會話保持）

基于Cookie實現的會話保持

基于Cookie實現會話保持與上述基于Session實現會話保持的最主要區別是前者完全將會話狀態信息存儲在瀏覽器Cookie中，這樣一來每次瀏覽器發送HTTP請求的時候都會帶上狀態信息，因此也就可以實現狀態保持。

兩者優缺點

基于Session的會話保持優點是安全性較高，因為狀態信息保存在服務器端。缺點是不便于服務器的水平擴展。大型網站的后臺一般都不止一臺服務器，可能幾臺甚至上百臺，瀏覽器發送的HTTP請求一般要先通過負載均衡器才能到達具體的后臺服務器，這就會導致每次HTTP請求可能落到不同的服務器上，比如說第一次HTTP請求落到server1上，第二次HTTP請求落到server2上。而Session默認是存儲在服務器本機內存的，當多次請求落到不同的服務器上時，上述方案就不能實現會話保持了（常用解決方案是中間件，例如Redis，將Session的信信息存儲在Redis中，這樣每個server就都可以訪問到）。

基于Cookie的會話保持的優點是服務器不用保存狀態信息，減輕服務端存儲壓力，也便于服務端做水平擴展。缺點是不夠安全，因為狀態信息是存儲在客戶端的，這意味著不能在會話中保存機密數據，另一個缺點是每次HTTP請求都需要發送額外的Cookie到服務端，會消耗更多帶寬。

Cookie 被禁用怎么辦?

URL重寫，就是把session id直接附加在URL路徑的后面。
最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。

Cookie的作用是什么?和Session有什么區別？

Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式，但是兩者的應用場景不太一樣。

Cookie 一般用來保存用戶信息比如①我們在 Cookie 中保存已經登錄過得用戶信息，下次訪問網站的時候頁面可以自動幫你登錄的一些基本信息給填了；②一般的網站都會有保持登錄也就是說下次你再訪問網站的時候就不需要重新登錄了，這是因為用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據 Token 值來查找用戶即可(為了安全考慮，重新登錄一般要將 Token 重寫)；③登錄一次網站后訪問網站其他頁面不需要重新登錄。Session 的主要作用就是通過服務端記錄用戶的狀態。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了。

Cookie 數據保存在客戶端(瀏覽器端)，Session 數據保存在服務器端。

Cookie 存儲在客戶端中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。

HTTP 1.0和HTTP 1.1的主要區別是什么?

1、長連接 : 在HTTP/1.0中，默認使用的是短連接，也就是說每次請求都要重新建立一次連接。HTTP 是基于TCP/IP協議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個長連接，可以用個長連接來發多個請求。HTTP 1.1起，默認使用長連接 ,默認開啟Connection： keep-alive。 HTTP/1.1的持續連接有非流水線方式和流水線方式。

2、錯誤狀態響應碼 :在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。

3、緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

4、帶寬優化及網絡連接的使用 :HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。

URI和URL的區別是什么?

URI(Uniform Resource Identifier) 是統一資源標志符，可以唯一標識一個資源。
URL(Uniform Resource Location) 是統一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明了如何 locate 這個資源。
URI的作用像身份證號一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的信息。

HTTP 和 HTTPS 的區別？

端口：HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。

安全性和資源消耗： HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。

對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；

非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

打開一個網址的過程，用到的協議

總體來說分為以下幾個過程:
1 DNS解析
2 TCP連接
3 發送HTTP請求
4 服務器處理請求并返回HTTP報文
5 瀏覽器解析渲染頁面
6 連接結束

應用層使用了HTTP協議進行超文本傳輸，對于服務器后臺處理應該有telnet遠程調用協議響應用戶，DNS協議獲取網絡地址，即IP地址；打開網頁，網頁顯示用到了表示層的HTML協議；
另外必然用到了傳輸層的TCP和網絡層的IP協議；網絡層ARP協議獲取物理地址（IP地址轉化為MAC地址）；ICMP協議控制信息的傳遞，還有很多吧，我就不知道了

HTTP，TCP，IP，DNS，ARP，ICMP（要對網路連接狀況進行判斷的時候）必然有

鍵??址到??顯示，期間發?了什么？

總體來說分為以下幾個過程:

瀏覽器解析URL，確定WEB服務器和文件名，根據這些信息生成HTTP請求信息。
DNS解析
TCP連接
客戶端發送HTTP請求
服務器處理請求并返回HTTP報文
瀏覽器解析渲染頁面
連接結束

總結

以上是生活随笔為你收集整理的6 计算机网络待更新的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

计算机网络

上一篇：成都开发者看过来！百度资深研发工程师将出
下一篇：单片机实验秒表设计程序c语言,如何使用单