本文整理自網(wǎng)絡(luò)，是自己在學習鞏固網(wǎng)絡(luò)相關(guān)知識點時整理的筆記，學習過程中自己思考的一些疑問點也邊查詢資料邊匯總。本文主要涉及TCP/UDP、HTTP發(fā)展史、HTTPS、WebSocket、DNS、網(wǎng)絡(luò)模型。

TCP vs UDP

TCP/IP協(xié)議是一個協(xié)議簇。里面包括很多協(xié)議的，UDP只是其中的一個， 之所以命名為TCP/IP協(xié)議，因為TCP、IP協(xié)議是兩個很重要的協(xié)議，就用他兩命名了。
TCP/IP協(xié)議集包括應(yīng)用層,傳輸層，網(wǎng)絡(luò)層，網(wǎng)絡(luò)訪問層。

TCP

概述

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。 一個TCP連接必須要經(jīng)過三次“對話”才能建立起來

名詞解釋

• ACK 是TCP報頭的控制位之一，對數(shù)據(jù)進行確認。確認由目的端發(fā)出， 用它來告訴發(fā)送端這個序列號之前的數(shù)據(jù)段都收到了。 比如確認號為X，則表示前X-1個數(shù)據(jù)段都收到了，只有當ACK=1時,確認號才有效，當ACK=0時，確認號無效，這時會要求重傳數(shù)據(jù)，保證數(shù)據(jù)的完整性。
• SYN 同步序列號，TCP建立連接時將這個位置1。
• FIN 發(fā)送端完成發(fā)送任務(wù)位，當TCP完成數(shù)據(jù)傳輸需要斷開時，提出斷開連接的一方將這位置1。

TCP三次握手過程

• 第一次握手：主機A通過向主機B 發(fā)送一個含有同步序列號的標志位的數(shù)據(jù)段給主機B，向主機B 請求建立連接，通過這個數(shù)據(jù)段， 主機A告訴主機B 兩件事：我想要和你通信；你可以用哪個序列號作為起始數(shù)據(jù)段來回應(yīng)我。
• 第二次握手：主機B 收到主機A的請求后，用一個帶有確認應(yīng)答（ACK）和同步序列號（SYN）標志位的數(shù)據(jù)段響應(yīng)主機A，也告訴主機A兩件事：我已經(jīng)收到你的請求了，你可以傳輸數(shù)據(jù)了；你要用那個序列號作為起始數(shù)據(jù)段來回應(yīng)我
• 第三次握手：主機A收到這個數(shù)據(jù)段后，再發(fā)送一個確認應(yīng)答，確認已收到主機B 的數(shù)據(jù)段："我已收到回復，我現(xiàn)在要開始傳輸實際數(shù)據(jù)了，這樣3次握手就完成了，主機A和主機B 就可以傳輸數(shù)據(jù)了。

3次握手的特點

沒有應(yīng)用層的數(shù)據(jù) ,SYN這個標志位只有在TCP建立連接時才會被置1 ,握手完成后SYN標志位被置0。

三次握手的作用

• 確認雙方的接受能力、發(fā)送能力是否正常。
• 指定自己的初始化序列號，為后面的可靠傳送做準備。
• 如果是 HTTPS 協(xié)議的話，三次握手這個過程，還會進行數(shù)字證書的驗證以及加密密鑰的生成。

TCP建立連接要進行3次握手，而斷開連接要進行4次（為什么TCP協(xié)議終止鏈接要四次？）

1、當主機A確認發(fā)送完數(shù)據(jù)且知道B已經(jīng)接受完了，想要關(guān)閉發(fā)送數(shù)據(jù)口（當然確認信號還是可以發(fā)），就會發(fā)FIN給主機B（將控制位FIN置1，提出停止TCP連接的請求 ）。
2、主機B收到A發(fā)送的FIN，表示收到了，就會發(fā)送ACK回復（將ACK置1）。
3、但這是B可能還在發(fā)送數(shù)據(jù)，沒有想要關(guān)閉數(shù)據(jù)口的意思，所以FIN與ACK不是同時發(fā)送的，而是等到B數(shù)據(jù)發(fā)送完了，才會發(fā)送FIN給主機A（將FIN置1 ）。
4、A收到B發(fā)來的FIN，知道B的數(shù)據(jù)也發(fā)送完了，回復ACK（將FIN置1 ）， A等待2MSL以后，沒有收到B傳來的任何消息，知道B已經(jīng)收到自己的ACK了，A就關(guān)閉鏈接，B也關(guān)閉鏈接了。

A為什么等待2MSL，從TIME_WAIT到CLOSE？

在Client發(fā)送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

為什么不能兩次握手能進行連接？

我們知道，3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認。
現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機S和C之間的通信，假定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā)送了確認應(yīng)答分組。按照兩次握手的協(xié)定，S認為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組?？墒?，C在S的應(yīng)答分組在傳輸中被丟失的情況下，將不知道S是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分組，只等待連接確認應(yīng)答分組。而S在發(fā)出的分組超時后，重復發(fā)送同樣的分組。這樣就形成了死鎖。

UDP

1、UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接， 當它想傳送時就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡(luò)上。 在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度、 計算機的能力和傳輸帶寬的限制； 在接收端，UDP把每個消息段放在隊列中，應(yīng)用程序每次從隊列中讀一個消息段。
2、 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護連接狀態(tài)，包括收發(fā)狀態(tài)等， 因此一臺服務(wù)機可同時向多個客戶機傳輸相同的消息。
3、UDP信息包的標題很短，只有8個字節(jié)，相對于TCP的20個字節(jié)信息包的額外開銷很小。
4、吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬、 源端和終端主機性能的限制。
5、UDP使用盡最大努力交付，即不保證可靠交付， 因此主機不需要維持復雜的鏈接狀態(tài)表（這里面有許多參數(shù)）。
6、UDP是面向報文的。發(fā)送方的UDP對應(yīng)用程序交下來的報文， 在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報文的邊界， 因此，應(yīng)用程序需要選擇合適的報文大小。

小結(jié)TCP與UDP的區(qū)別：

1、基于連接與無連接；
2、對系統(tǒng)資源的要求（TCP較多，UDP少）；
3、UDP程序結(jié)構(gòu)較簡單；
4、流模式與數(shù)據(jù)報模式 ；
5、TCP保證數(shù)據(jù)正確性，UDP可能丟包；
6、TCP保證數(shù)據(jù)順序，UDP不保證。

TCP和UDP協(xié)議的一些應(yīng)用

HTTP發(fā)展史

HTTP 0.9 只有g(shù)et請求

HTTP 1.0

優(yōu)化點：

• 增加了post命令和head命令
• HTTP請求和回應(yīng)的格式也變了
• 支持發(fā)送任何格式的內(nèi)容
• 其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等。

缺點：

• 連接無法復用。瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接（即每次都需要進行TCP三次握手），服務(wù)器不跟蹤每個客戶也不記錄過去的請求。（有些瀏覽器在請求時，用了一個非標準的Connection字段，Connection: keep-alive，但是，這不是標準字段，不同實現(xiàn)的行為可能不一致）
• Head-Of-Line Blocking（HOLB，隊頭阻塞）。HOLB 是指一系列包（package）因為第一個包被阻塞；HOLB 會導致在達到最大請求數(shù)量時，剩余的資源需要等待其它資源請求完成后才能發(fā)起請求。

HTTP 1.1

1997 年 1 月，發(fā)布 HTTP/1.1 版本，只比 1.0 版本晚了半年。直到現(xiàn)在還是最流行的版本。
優(yōu)化點：

• 緩存處理。引入了更多的緩存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
• 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用。在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
• 錯誤通知的管理。在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼。
• Host頭處理，在HTTP1.0中認為每臺服務(wù)器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
• 長鏈接。引入了持久連接（persistent connection），即TCP連接默認不關(guān)閉，可以被多個請求復用，不用聲明Connection: keep-alive。（目前，對于同一個域名，大多數(shù)瀏覽器允許同時建立6個持久連接。）
• 1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

缺點：

• 雖然加入 keep-alive 可以復用一部分連接，但域名分片等情況下仍然需要建立多個 connection，耗費資源，給服務(wù)器帶來性能壓力。
• HTTP 1.1 嘗試使用 pipeling 來解決隊頭阻塞問題，即瀏覽器可以一次性發(fā)出多個請求（同個域名、同一條 TCP 鏈接）。但 pipeling 要求返回是按序的，那么前一個請求如果很耗時（比如處理大圖片），那么后面的請求即使服務(wù)器已經(jīng)處理完，仍會等待前面的請求處理完才開始按序返回。
• header 里攜帶的內(nèi)容過大，在一定程度上增加了傳輸?shù)某杀荆⑶颐看握埱?header 基本不怎么變化，尤其在移動端增加用戶流量。

HTTP 2.0

SPDY是2012年谷歌推出的是基于SSL/TLS的傳輸協(xié)議，SPDY有降低延遲，多路復用，頭部壓縮，服務(wù)端推送等特點，這些特點也稱為了后續(xù)HTTP2.0的功能基石，HTTP2.0是SPDY/3 draft的優(yōu)化版。

HTTP2.0 與 SPDY的區(qū)別：

HTTP2.0 頭部壓縮采用HPACK， 而SPDY采用DELEFT。
HTTP2.0 理論上支持明文HTTP傳輸，而SPDY強制使用HTTPS。

SPDY 協(xié)議是在 TCP 協(xié)議之上。

• 相比 HTTP/1 的文本格式，HTTP/2 采用二進制格式傳輸數(shù)據(jù)，解析起來更高效。
• 同時，還支持對 Header 壓縮，減少頭部的包體積大小。

• HTTP 2.0 還引入了多路復用技術(shù)。多路復用很好地解決了瀏覽器限制同一個域名下的請求數(shù)量的問題，同時也更容易實現(xiàn)全速傳輸，畢竟新開一個 TCP 連接都需要慢慢提升傳輸速度。

  
  
  image.png

HTTP 3.0

TCP 協(xié)議雖然能保證不丟包，但還是存在一些局限性。谷歌為了提高Web聯(lián)網(wǎng)的速度決定推倒重來，吸收 TCP 快速打開的技術(shù)，緩存當前會話的上下文等優(yōu)點，基于 UDP 協(xié)議研發(fā)一種名為QUIC （全稱是“快速UDP互聯(lián)網(wǎng)連接”）的實驗性網(wǎng)絡(luò)協(xié)議

Quic

Quic 全稱 quick udp internet connection，“快速 UDP 互聯(lián)網(wǎng)連接”，（和英文 quick 諧音，簡稱“快”）是由 google 提出的使用 udp 進行多路并發(fā)傳輸?shù)膮f(xié)議。它不但具有TCP的可靠性、擁塞控制、流量控制等，且在TCP協(xié)議的基礎(chǔ)上做了一些改進，比如避免了隊首阻塞；另外，QUIC協(xié)議具有TLS的安全傳輸特性，實現(xiàn)了TLS的保密功能，同時又使用更少的RTT建立安全的會話。
Quic 相比現(xiàn)在廣泛應(yīng)用的 http2+tcp+tls 協(xié)議有如下優(yōu)勢：

• 減少了 TCP 三次握手及 TLS 握手時間。
• 改進的擁塞控制。
• 避免隊頭阻塞的多路復用。
• 連接遷移。
• 前向冗余糾錯。

科普：QUIC 協(xié)議原理分析

HTTP相關(guān)問題

每次 HTTP 都需要三次握手嗎？

HTTP協(xié)議是在TCP協(xié)議之上的，所以建立一個HTTP連接就需要一次三次握手的過程。但是HTTP有持續(xù)連接和非持久連接的區(qū)分，就是HTTP請求首部里面的Connection字段，如果是Connection:Keep-Alive就表示持續(xù)連接，除非一方主動斷開，客戶端和服務(wù)器的網(wǎng)絡(luò)連接是持續(xù)的，也就是多個HTTP請求都是這一個網(wǎng)絡(luò)連接；如果是Connection:close，一個HTTP請求在獲得HTTP響應(yīng)后連接就會斷開，在下一次HTTP請求時就會有另外一次HTTP連接，也就會再有一個三次握手的過程。http 1.1中默認啟用Keep-Alive，如果加入"Connection: close "，才關(guān)閉。

什么是長鏈接

HTTP1.1規(guī)定了默認保持長連接（HTTP persistent connection ，也有翻譯為持久連接），數(shù)據(jù)傳輸完成了保持TCP連接不斷開（不發(fā)RST包、不四次握手），等待在同域名下繼續(xù)用這個通道傳輸數(shù)據(jù)；相反的就是短連接。

長連接的過期時間

客戶端的長連接不可能無限期的拿著，會有一個超時時間，服務(wù)器有時候會告訴客戶端超時時間，譬如：

上圖中的Keep-Alive: timeout=20，表示這個TCP通道可以保持20秒。另外還可能有max=XXX，表示這個長連接最多接收XXX次請求就斷開。對于客戶端來說，如果服務(wù)器沒有告訴客戶端超時時間也沒關(guān)系，服務(wù)端可能主動發(fā)起四次握手斷開TCP連接，客戶端能夠知道該TCP連接已經(jīng)無效；另外TCP還有心跳包來檢測當前連接是否還活著，方法很多，避免浪費資源。

瀏覽器并發(fā)連接的數(shù)量限制

RFC文檔說，客戶端與服務(wù)器最多就連上兩通道，但服務(wù)器、個人客戶端要不要這么做就隨人意了，有些服務(wù)器就限制同時只能有1個TCP連接，導致客戶端的多線程下載（客戶端跟服務(wù)器連上多條TCP通道同時拉取數(shù)據(jù)）發(fā)揮不了威力，有些服務(wù)器則沒有限制。瀏覽器客戶端就比較規(guī)矩，限制了同域名下能啟動若干個并發(fā)的TCP連接去下載資源。(在HTTP1.x中，并發(fā)多個請求需要多個TCP連接，瀏覽器為了控制資源會有6-8個TCP連接都限制)
并發(fā)數(shù)量的限制也跟長連接有關(guān)聯(lián)，打開一個網(wǎng)頁，很多個資源的下載可能就只被放到了少數(shù)的幾條TCP連接里，這就是TCP通道復用（長連接）。如果并發(fā)連接數(shù)少，意味著網(wǎng)頁上所有資源下載完需要更長的時間（用戶感覺頁面打開卡了）；并發(fā)數(shù)多了，服務(wù)器可能會產(chǎn)生更高的資源消耗峰值。瀏覽器只對同域名下的并發(fā)連接做了限制，也就意味著，web開發(fā)者可以把資源放到不同域名下，同時也把這些資源放到不同的機器上，這樣就完美解決了。

HTTP 2.0 服務(wù)端推送

請求不是來自客戶端“明確”的請求，是從服務(wù)端PUSH_PROMISE幀中提供。例如我們加載index.html, 我們可能還需要index.js, index.css等文件。傳統(tǒng)的請求只有當拿到index.html，解析html中對index.js/index.css的引入才會再請求資源加載，但是通過服務(wù)端數(shù)據(jù)，可以提前將資源推送給客戶端，這樣客戶端要用到的時候直接調(diào)用即可，不用再發(fā)送請求。

• push的資源能緩存在瀏覽器中
• 不同的網(wǎng)頁能使用該緩存，不用重新發(fā)起
• push的資源通過multiplexed進行傳輸
• push的資源能夠進行priority標識
• client有權(quán)取消push資源的加載
• push的資源必須同域

容易混淆的概念

TCP的KeepAlive和HTTP的Keep-alive：

• “KeepAlive”，TCP的keep alive是檢查當前TCP連接是否活著，是為了保證連接是健康的，如即時通訊技術(shù)需要用到；TCP keep alive的表現(xiàn)：當一個連接“一段時間”沒有數(shù)據(jù)通訊時，一方會發(fā)出一個心跳包（Keep Alive包），如果對方有回包則表明當前連接有效，繼續(xù)監(jiān)控。
• “Keep-Alive”, HTTP的Keep-alive是要讓一個TCP連接活久點，為了連接復用，即減少多余的TCP請求。

TCP復用和HTTP復用

TCP復用：TCP連接復用是將多個客戶端的HTTP請求復用到一個服務(wù)器端TCP連接上。
HTTP復用（HTTP多路復用技術(shù)）：一個客戶端的多個HTTP請求通過一個TCP連接進行處理。
前者是負載均衡設(shè)備的獨特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。

TCP復用

TCP連接復用技術(shù)通過將前端多個客戶的HTTP請求復用到后端與服務(wù)器建立的一個TCP連接上。這種技術(shù)能夠大大減小服務(wù)器的性能負載，減少與服務(wù)器之間新建TCP連接所帶來的延時，并最大限度的降低客戶端對后端服務(wù)器的并發(fā)連接數(shù)請求，減少服務(wù)器的資源占用。
采用TCP連接復用技術(shù)后，客戶端（如：ClientA）與負載均衡設(shè)備之間進行三次握手并發(fā)送HTTP請求。負載均衡設(shè)備收到請求后，會檢測服務(wù)器是否存在空閑的長連接，如果不存在，服務(wù)器將建立一個新連接。當HTTP請求響應(yīng)完成后，客戶端則與負載均衡設(shè)備協(xié)商關(guān)閉連接，而負載均衡則保持與服務(wù)器之間的這個連接。當有其它客戶端（如：ClientB）需要發(fā)送HTTP請求時，負載均衡設(shè)備會直接向與服務(wù)器之間保持的這個空閑連接發(fā)送HTTP請求，避免了由于新建TCP連接造成的延時和服務(wù)器資源耗費。

HTTP流水線技術(shù)(HTTP 1.1)與HTTP多路復用技術(shù)(HTTP 2.0)

HTTP 流水線技術(shù)

HTTP 1.1 流水線技術(shù)9(HTTP pipelining，也有翻譯為管道化連接)，它是指，在一個TCP連接內(nèi)，多個HTTP請求可以并行，下一個HTTP請求在上一個HTTP請求的應(yīng)答完成之前就發(fā)起。
由于要求服務(wù)端返回響應(yīng)數(shù)據(jù)的順序必須跟客戶端請求時的順序一致，這樣也就是要求FIFO，這容易導致隊頭阻塞(Head-of-line blocking)：第一個請求的響應(yīng)發(fā)送影響到了后邊的請求，因為這個原因?qū)е翲TTP流水線技術(shù)對性能的提升并不明顯。(前一個請求如果很耗時，那么后面的請求即使服務(wù)器已經(jīng)處理完，仍會等待前面的請求處理完才開始按序返回)

HTTP多路復用技術(shù)

在 HTTP/2 中，有兩個非常重要的概念，分別是幀（frame）和流（stream）。幀代表著最小的數(shù)據(jù)單位，每個幀會標識出該幀屬于哪個流，流也就是多個幀組成的數(shù)據(jù)流。
多路復用，就是在一個 TCP 連接中可以存在多條流。在復用同一個TCP連接時，服務(wù)器同時/先后收到了A、B兩個請求，先回應(yīng)A請求，但由于處理過程非常耗時，于是服務(wù)端就把已經(jīng)處理好的部分先發(fā)送， 然后回應(yīng)B請求，完成后，再發(fā)送A請求剩下的部分?？蛻舳?服務(wù)端發(fā)送/接收數(shù)據(jù)時，會將數(shù)據(jù)打散亂序發(fā)送，接收數(shù)據(jù)時接收一端再通過streamID標識來將數(shù)據(jù)合并。

常見的HTTP相應(yīng)狀態(tài)碼有哪些呢？

200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務(wù)器只對請求的部分資源執(zhí)行GET方法，相應(yīng)報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務(wù)器無法識別
401：請求需要認證
403：請求的對應(yīng)資源禁止被訪問
404：服務(wù)器無法找到對應(yīng)資源
500：服務(wù)器內(nèi)部錯誤
503：服務(wù)器正忙

image.png

HTTPS

HTTPS經(jīng)由HTTP進行通信，但利用SSL/TLS來加密數(shù)據(jù)包。HTTPS 是 HTTP 的安全版，是使用 SSL/TLS 加密的 HTTP 協(xié)議。

名詞解釋

對稱加密：兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。
非對稱加密：有公鑰私鑰之分，公鑰所有人都可以知道，可以將數(shù)據(jù)用公鑰加密，但是將數(shù)據(jù)解密必須使用私鑰解密，私鑰只有分發(fā)公鑰的一方才知道。
RSA加密算法：一種非對稱加密算法。在公開密鑰加密和電子商業(yè)中RSA被廣泛使用。
RTT(Round-Trip Time)：: 往返時延。在計算機網(wǎng)絡(luò)中它是一個重要的性能指標，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認（接收端收到數(shù)據(jù)后便立即發(fā)送確認），總共經(jīng)歷的時延。

SSL/TLS

SSL(Secure Socket Layer) 安全套接層
TLS(Transport Layer Security) 傳輸層安全
TLS 協(xié)議位于傳輸層之上，應(yīng)用層之下。

1994年，NetScape公司設(shè)計了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規(guī)模應(yīng)用。
1999年，互聯(lián)網(wǎng)標準化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。

目前，應(yīng)用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持。
TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

SSL/TLS協(xié)議是為了解決這三大風險而設(shè)計的，希望達到：
（1）所有信息都是加密傳播，第三方無法竊聽。
（2）具有校驗機制，一旦被篡改，通信雙方會立刻發(fā)現(xiàn)。
（3）配備身份證書，防止身份被冒充。

TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法，一般使用的加密與HASH算法如下：
非對稱加密算法：RSA，DSA/DSS
對稱加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

通信過程

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。
SSL/TLS協(xié)議的基本過程是這樣的：
（1） 客戶端向服務(wù)器端索要并驗證公鑰。
（2） 雙方協(xié)商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）。

詳細步驟

一、客戶端向服務(wù)端發(fā)送請求
1)支持的協(xié)議版本, eg:TSL1.0
2)支持的加密和壓縮算法
3)產(chǎn)生隨機數(shù)a
二、服務(wù)端回應(yīng)并返回數(shù)字證書
1)確定加密協(xié)議版本和加密算法，如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
2)返回證書
3)產(chǎn)生隨機數(shù)b
三、客戶端驗證證書
1)客戶端用自己的CA公鑰去解密證書，如果證書有問題則提示風險
2)生成隨機數(shù)c(又稱"pre-master key")，使用服務(wù)端的公鑰進行加密，防止被竊聽，發(fā)送給服務(wù)端
3)編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
4)客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗。
四、服務(wù)端用三個隨機數(shù)和算法生成session密鑰
1)編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
2)服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供客戶端校驗。

之后雙方就拿著這個對稱加密秘鑰來進行正常的通信，接下來完全是使用普通的HTTP協(xié)議，只不過用"會話密鑰"加密內(nèi)容。
總結(jié)：SSL協(xié)議進行了4次通信，在握手階段使用的是非對稱加密，在傳輸階段使用的是對稱加密。

SSL/TLS協(xié)議通信過程

相關(guān)問題

如何保證公鑰不被篡改？

將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

公鑰加密計算量太大，如何減少耗用的時間？

每一次對話（session），客戶端和服務(wù)器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非?？?，而服務(wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

為什么一定要用三個隨機數(shù)，來生成"會話密鑰"

"不管是客戶端還是服務(wù)器，都需要隨機數(shù)，這樣生成的密鑰才不會每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數(shù)，再加上hello消息中的隨機，三個隨機數(shù)通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)，如果隨機數(shù)不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務(wù)器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"

HTTP 與HTTPS的區(qū)別是什么？

• HTTP 的 URL 以 http:// 開頭，而 HTTPS 的URL 以 https:// 開頭
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 標準端口是80，而 HTTPS 的標準端口是443
• 在OSI 網(wǎng)絡(luò)模型中，HTTP工作于應(yīng)用層，而HTTPS 的安全傳輸機制工作在傳輸層
• HTTP 無法加密，而HTTPS 對傳輸?shù)臄?shù)據(jù)進行加密
• HTTP無需證書，而HTTPS 需要CA機構(gòu)wosign的頒發(fā)的SSL證書

一篇文章徹底了解HTTP發(fā)展史
常見的HTTP狀態(tài)碼(HTTP Status Code)
HTTP的長連接和短連接
TCP連接復用
雜談：HTTP1.1 與 HTTP2.0 知多少？
SSL/TLS協(xié)議運行機制的概述
HTTP常見面試題

WebSocket

HTTP 協(xié)議通信只能由客戶端發(fā)起，很多網(wǎng)站為了實現(xiàn)推送技術(shù)，所用的技術(shù)都是輪詢。輪詢是在特定的的時間間隔（如每秒），由瀏覽器對服務(wù)器發(fā)出HTTP請求，然后由服務(wù)器返回最新的數(shù)據(jù)給客戶端的瀏覽器。這種傳統(tǒng)的模式帶來很明顯的缺點，即瀏覽器需要不斷的向服務(wù)器發(fā)出請求，然而HTTP請求可能包含較長的頭部，其中真正有效的數(shù)據(jù)可能只是很小的一部分，顯然這樣會消耗很多的帶寬資源。

WebSocket 協(xié)議在2008年誕生，2011年成為國際標準。所有瀏覽器都已經(jīng)支持了。
它的最大特點就是，服務(wù)器可以主動向客戶端推送信息，客戶端也可以主動向服務(wù)器發(fā)送信息，是真正的雙向平等對話，屬于服務(wù)器推送技術(shù)的一種。

• WebSocket 是獨立的、創(chuàng)建在 TCP協(xié)議之上，服務(wù)器端的實現(xiàn)比較容易。
• 與 HTTP 協(xié)議有著良好的兼容性。默認情況下，Websocket協(xié)議使用80端口；運行在TLS之上時，默認使用443端口。握手階段采用 HTTP 協(xié)議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務(wù)器。
• 數(shù)據(jù)格式比較輕量，性能開銷小，通信高效。
• 可以發(fā)送文本，也可以發(fā)送二進制數(shù)據(jù)。
• 沒有同源限制，客戶端可以與任意服務(wù)器通信。
• 協(xié)議標識符是ws（如果加密，則為wss），服務(wù)器網(wǎng)址就是 URL。
• Websocket 通過HTTP/1.1 協(xié)議的101狀態(tài)碼進行握手。
• 為了創(chuàng)建Websocket連接，需要通過瀏覽器發(fā)出請求，之后服務(wù)器進行回應(yīng)，這個過程通常稱為“握手”（handshaking）。

優(yōu)點

• 較少的控制開銷。(數(shù)據(jù)包頭部)
• 更強的實時性。
• 保持連接狀態(tài)。
• 更好的二進制支持。
• 可以支持擴展。
• 更好的壓縮效果。

WebSocket 教程

DNS

什么是 DNS

DNS（Domain Name System，域名系統(tǒng)），是互聯(lián)網(wǎng)上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫。DNS 服務(wù)用于在網(wǎng)絡(luò)請求時，將域名轉(zhuǎn)為 IP 地址。能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的 IP 數(shù)串。
傳統(tǒng)的基于 UDP 協(xié)議的公共 DNS 服務(wù)極易發(fā)生 DNS 劫持，從而造成安全問題。

DNS解析過程

1.瀏覽器中輸入 www.linkedkeeper.com，發(fā)出解析請求。
2.本機的域名解析器 resolver 程序查詢本地緩存和 host 文件中是否為域名的映射關(guān)系，如果有則調(diào)用這個 IP 地址映射，完成解析。
3.如果 hosts 與本地解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，則本地解析器會向 TCP/IP 參數(shù)中設(shè)置的首選 DNS 服務(wù)器（我們叫它 Local DNS 服務(wù)器）發(fā)起一個遞歸的查詢請求。
4.服務(wù)器收到查詢時，如果要查詢的域名由本機負責解析，則返回解析結(jié)果給客戶機，完成域名解析，此解析具有權(quán)威性。如果要查詢的域名，不由 Local DNS 服務(wù)器解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個 IP 地址映射，完成域名解析，此解析不具有權(quán)威性。
5.如果 Local DNS 服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù) Local DNS 服務(wù)器的設(shè)置（是否遞歸）進行查詢，如果未用開啟模式，Local DNS 就把請求發(fā)至13臺 Root DNS。如果用的是遞歸模式，此 DNS 服務(wù)器就會把請求轉(zhuǎn)發(fā)至上一級 DNS 服務(wù)器，由上一級服務(wù)器進行解析，上一級服務(wù)器如果不能解析，或找根 DNS 或把轉(zhuǎn)請求轉(zhuǎn)至上上級，以此循環(huán)。
6.Root DNS 服務(wù)器收到請求后會判斷這個域名是誰來授權(quán)管理，并會返回一個負責該頂級域名服務(wù)器的一個 IP。
7.Local DNS 服務(wù)器收到 IP 信息后，將會聯(lián)系負責 .com 域的這臺服務(wù)器。
8.負責 .com 域的服務(wù)器收到請求后，如果自己無法解析，它就會找一個管理 .com 域的下一級 DNS 服務(wù)器地址給本地 DNS 服務(wù)器。
9.當 Local DNS 服務(wù)器收到這個地址后，就會找 linkedkeeper.com 域服務(wù)器，10、11重復上面的動作，進行查詢。
10.最后 www.linkedkeeper.com 返回需要解析的域名的 IP 地址給 Local DNS 服務(wù)器。
11.Local DNS 服務(wù)器緩存這個解析結(jié)果（同時也會緩存，6、8、10返回的結(jié)果）。
12.Local DNS 服務(wù)器同時將結(jié)果返回給本機域名解析器。
13.本機緩存解析結(jié)果。
14.本機解析器將結(jié)果返回給瀏覽器。
15.瀏覽器通過返回的 IP 地址發(fā)起請求。

遞歸查詢和迭代查詢

遞歸查詢：如果主機所詢問的本地域名服務(wù)器不知道被查詢域名的 IP 地址，那么本地域名服務(wù)器就以 DNS 客戶的身份，向其他根域名服務(wù)器繼續(xù)發(fā)出查詢請求報文，而不是讓該主機自己進行下一步的查詢。
迭代查詢：當根域名服務(wù)器收到本地域名服務(wù)器發(fā)出的迭代查詢請求報文時，要么給出所要查詢的 IP 地址，要么告訴本地域名服務(wù)器：你下一步應(yīng)當向哪一個域名服務(wù)器進行查詢。然后讓本地域名服務(wù)器進行后續(xù)的查詢，而不是替本地域名服務(wù)器進行后續(xù)的查詢。

由此可見，客戶端到 Local DNS 服務(wù)器，Local DNS 與上級 DNS 服務(wù)器之間屬于遞歸查詢；DNS 服務(wù)器與根 DNS 服務(wù)器之前屬于迭代查詢。
實際環(huán)境中，因為采用遞歸模式會導致 DNS 服務(wù)器流量很大，所以現(xiàn)在大多數(shù)的 DNS 都是迭代模式。

域名劫持的幾種方法

1.假扮域名注冊人和域名注冊商通信；
2.偽造域名注冊人在注冊商處的賬戶信息；
3.偽造域名注冊人的域名轉(zhuǎn)移請求；
4.直接進行一次域名轉(zhuǎn)移請求；
5.修改域名的DNS記錄。

HttpDNS 是什么

HttpDNS 利用 HTTP 協(xié)議與 DNS 服務(wù)器交互，代替了傳統(tǒng)的基于 UDP 協(xié)議的 DNS 交互，繞開了運營商的 Local DNS，有效防止了域名劫持，提高域名解析效率。另外，由于 DNS 服務(wù)器端獲取的是真實客戶端 IP 而非 Local DNS 的 IP，能夠精確定位客戶端地理位置、運營商信息，從而有效改進調(diào)度精確性。

HttpDNS 主要解決的問題

• Local DNS 劫持：由于 HttpDns 是通過 IP 直接請求 HTTP 獲取服務(wù)器 A 記錄地址，不存在向本地運營商詢問 domain 解析過程，所以從根本避免了劫持問題。
• 平均訪問延遲下降：由于是 IP 直接訪問省掉了一次 domain 解析過程，通過智能算法排序后找到最快節(jié)點進行訪問。
• 用戶連接失敗率下降：通過算法降低以往失敗率過高的服務(wù)器排序，通過時間近期訪問過的數(shù)據(jù)提高服務(wù)器排序，通過歷史訪問成功記錄提高服務(wù)器排序。

目前，國內(nèi)有一部分廠商已經(jīng)提供了這個解析服務(wù)，可以直接使用第三方服務(wù)。直接發(fā)一個 Get 請求，帶上請求參數(shù)，返回結(jié)果以 json 返回。

http://xxxxxx?host=www.linkedkeeper.com

請求成功時，返回結(jié)果如下：

{
  "host": "www.linkedkeeper.com",
  "ips": [
    "115.238.23.241",
    "115.238.23.251"
  ],
  "ttl": 57
}

在移動端，將由 HttpDns 獲得的 IP 地址在原有 URL 的基礎(chǔ)上，將域名替換為 IP，然后用新的 URL 發(fā)起 HTTP 請求。

HttpDns 原理是什么
域名劫持的幾種方法
DNS域名劫持的幾種方式及解決方法

互聯(lián)網(wǎng)協(xié)議入門

ISO/OSI七層網(wǎng)絡(luò)參考模型：應(yīng)用層、表示層、會話層、運輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。
/IP四層網(wǎng)絡(luò)模型：應(yīng)用層、運輸層、網(wǎng)絡(luò)層和網(wǎng)絡(luò)接口層。
五層網(wǎng)絡(luò)模型：應(yīng)用層、運輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。
如何分層有不同的模型，有的模型分七層，有的分四層。只需要知道，互聯(lián)網(wǎng)分成若干層就可以了。
互聯(lián)網(wǎng)的每一層，都定義了很多協(xié)議。這些協(xié)議的總稱，就叫做"互聯(lián)網(wǎng)協(xié)議"（Internet Protocol Suite）。它們是互聯(lián)網(wǎng)的核心，下面介紹每一層的功能，主要就是介紹每一層的主要協(xié)議。

網(wǎng)絡(luò)模型

image.png

實體層 / 物理層

它就是把電腦連接起來的物理手段。它主要規(guī)定了網(wǎng)絡(luò)的一些電氣特性，作用是負責傳送0和1的電信號。

鏈接層 / 數(shù)據(jù)鏈路層

"鏈接層"的功能，它在"實體層"的上方，確定了0和1的分組方式。
早期的時候，每家公司都有自己的電信號分組方式。逐漸地，一種叫做"以太網(wǎng)"（Ethernet）的協(xié)議，占據(jù)了主導地位。以太網(wǎng)規(guī)定，一組電信號構(gòu)成一個數(shù)據(jù)包，叫做"幀"（Frame）。每一幀分成兩個部分：標頭（Head）和數(shù)據(jù)（Data）。

• "標頭"包含數(shù)據(jù)包的一些說明項，比如發(fā)送者、接受者、數(shù)據(jù)類型等等；"數(shù)據(jù)"則是數(shù)據(jù)包的具體內(nèi)容。
• "標頭"的長度，固定為18字節(jié)。"數(shù)據(jù)"的長度，最短為46字節(jié)，最長為1500字節(jié)。如果數(shù)據(jù)很長，就必須分割成多個幀進行發(fā)送。
• 以太網(wǎng)規(guī)定，連入網(wǎng)絡(luò)的所有設(shè)備，都必須具有"網(wǎng)卡"接口。數(shù)據(jù)包必須是從一塊網(wǎng)卡，傳送到另一塊網(wǎng)卡。網(wǎng)卡的地址，就是數(shù)據(jù)包的發(fā)送地址和接收地址，這叫做MAC地址。每塊網(wǎng)卡出廠的時候，都有一個全世界獨一無二的MAC地址，長度是48個二進制位，通常用12個十六進制數(shù)表示。前6個十六進制數(shù)是廠商編號，后6個是該廠商的網(wǎng)卡流水號。eg:00-B0-D0-86-BB-F7
• 1號計算機向2號計算機發(fā)送一個數(shù)據(jù)包，同一個子網(wǎng)絡(luò)的3號、4號、5號計算機都會收到這個包。它們讀取這個包的"標頭"，找到接收方的MAC地址，然后與自身的MAC地址相比較，如果兩者相同，就接受這個包，做進一步處理，否則就丟棄這個包。這種發(fā)送方式就叫做"廣播"（broadcasting）。

image.png

網(wǎng)絡(luò)層

• 如果兩臺計算機不在同一個子網(wǎng)絡(luò)，廣播是傳不過去的。
• 如果是同一個子網(wǎng)絡(luò)，就采用廣播方式發(fā)送，否則就采用"路由"方式發(fā)送。
• 這就導致了"網(wǎng)絡(luò)層"的誕生。它的作用是引進一套新的地址，使得我們能夠區(qū)分不同的計算機是否屬于同一個子網(wǎng)絡(luò)。這套地址就叫做"網(wǎng)絡(luò)地址"，簡稱"網(wǎng)址"。

IP協(xié)議

• 規(guī)定網(wǎng)絡(luò)地址的協(xié)議，叫做IP協(xié)議。它所定義的地址，就被稱為IP地址。目前，廣泛采用的是IP協(xié)議第四版，簡稱IPv4。這個版本規(guī)定，網(wǎng)絡(luò)地址由32個二進制位組成。習慣上，我們用分成四段的十進制數(shù)表示IP地址，從0.0.0.0一直到255.255.255.255。
• 互聯(lián)網(wǎng)上的每一臺計算機，都會分配到一個IP地址。這個地址分成兩個部分，前一部分代表網(wǎng)絡(luò)，后一部分代表主機。
• 通過"子網(wǎng)掩碼"判斷兩臺計算機是否屬于同一個子網(wǎng)絡(luò)。
• 總結(jié)一下，IP協(xié)議的作用主要有兩個，一個是為每一臺計算機分配IP地址，另一個是確定哪些地址在同一個子網(wǎng)絡(luò)。

IP數(shù)據(jù)包

• 把IP數(shù)據(jù)包直接放進以太網(wǎng)數(shù)據(jù)包的"數(shù)據(jù)"部分，因此完全不用修改以太網(wǎng)的規(guī)格。這就是互聯(lián)網(wǎng)分層結(jié)構(gòu)的好處：上層的變動完全不涉及下層的結(jié)構(gòu)。

• IP數(shù)據(jù)包的"標頭"部分的長度為20到60字節(jié)，整個數(shù)據(jù)包的總長度最大為65,535字節(jié)。因此，理論上，一個IP數(shù)據(jù)包的"數(shù)據(jù)"部分，最長為65,515字節(jié)。前面說過，以太網(wǎng)數(shù)據(jù)包的"數(shù)據(jù)"部分，最長只有1500字節(jié)。因此，如果IP數(shù)據(jù)包超過了1500字節(jié)，它就需要分割成幾個以太網(wǎng)數(shù)據(jù)包，分開發(fā)送了。

  
  
  image.png

ARP協(xié)議

傳輸層

• 當一個數(shù)據(jù)包從互聯(lián)網(wǎng)上發(fā)來的時候，怎么知道，它是表示網(wǎng)頁的內(nèi)容，還是表示在線聊天的內(nèi)容？我們需要一個參數(shù)，表示這個數(shù)據(jù)包到底供哪個程序（進程）使用。這個參數(shù)就叫做"端口"（port），它其實是每一個使用網(wǎng)卡的程序的編號。每個數(shù)據(jù)包都發(fā)到主機的特定端口，所以不同的程序就能取到自己所需要的數(shù)據(jù)。
• "端口"是0到65535之間的一個整數(shù)，正好16個二進制位。0到1023的端口被系統(tǒng)占用，用戶只能選用大于1023的端口。不管是瀏覽網(wǎng)頁還是在線聊天，應(yīng)用程序會隨機選用一個端口，然后與服務(wù)器的相應(yīng)端口聯(lián)系。
• "傳輸層"的功能，就是建立"端口到端口"的通信。相比之下，"網(wǎng)絡(luò)層"的功能是建立"主機到主機"的通信。只要確定主機和端口，我們就能實現(xiàn)程序之間的交流。

UDP協(xié)議

• UDP數(shù)據(jù)包，也是由"標頭"和"數(shù)據(jù)"兩部分組成。
• "標頭"部分主要定義了發(fā)出端口和接收端口，"數(shù)據(jù)"部分就是具體的內(nèi)容。
• UDP數(shù)據(jù)包非常簡單，"標頭"部分一共只有8個字節(jié)，總長度不超過65,535字節(jié)，正好放進一個IP數(shù)據(jù)包。
• UDP協(xié)議的優(yōu)點是比較簡單，容易實現(xiàn)，但是缺點是可靠性較差，一旦數(shù)據(jù)包發(fā)出，無法知道對方是否收到。

image.png

TCP協(xié)議

• 它就是有確認機制的UDP協(xié)議，每發(fā)出一個數(shù)據(jù)包都要求確認。如果有一個數(shù)據(jù)包遺失，就收不到確認，發(fā)出方就知道有必要重發(fā)這個數(shù)據(jù)包了。
• TCP協(xié)議能夠確保數(shù)據(jù)不會遺失。它的缺點是過程復雜、實現(xiàn)困難、消耗較多的資源。
• TCP數(shù)據(jù)包沒有長度限制，理論上可以無限長，但是為了保證網(wǎng)絡(luò)的效率，通常TCP數(shù)據(jù)包的長度不會超過IP數(shù)據(jù)包的長度，以確保單個TCP數(shù)據(jù)包不必再分割。

應(yīng)用層

• "應(yīng)用層"的作用，就是規(guī)定應(yīng)用程序的數(shù)據(jù)格式。
• TCP協(xié)議可以為各種各樣的程序傳遞數(shù)據(jù)，比如Email、WWW、FTP等等。那么，必須有不同協(xié)議規(guī)定電子郵件、網(wǎng)頁、FTP數(shù)據(jù)的格式，這些應(yīng)用程序協(xié)議就構(gòu)成了"應(yīng)用層"。
• 這是最高的一層，直接面對用戶。它的數(shù)據(jù)就放在TCP數(shù)據(jù)包的"數(shù)據(jù)"部分。

image.png

用戶的上網(wǎng)設(shè)置

• 計算機每次開機，都會分到同樣的IP地址，所以這種情況被稱作"靜態(tài)IP地址上網(wǎng)"。
• 所謂"動態(tài)IP地址"，指計算機開機后，會自動分配到一個IP地址，不用人為設(shè)定。它使用的協(xié)議叫做DHCP協(xié)議。
• 這個協(xié)議規(guī)定，每一個子網(wǎng)絡(luò)中，有一臺計算機負責管理本網(wǎng)絡(luò)的所有IP地址，它叫做"DHCP服務(wù)器"。新的計算機加入網(wǎng)絡(luò)，必須向"DHCP服務(wù)器"發(fā)送一個"DHCP請求"數(shù)據(jù)包，申請IP地址和相關(guān)的網(wǎng)絡(luò)參數(shù)。
• DNS協(xié)議將網(wǎng)址轉(zhuǎn)換成IP地址。已知DNS服務(wù)器為8.8.8.8，于是我們向這個地址發(fā)送一個DNS數(shù)據(jù)包（53端口）。然后，DNS服務(wù)器做出響應(yīng)，告訴我們Google的IP地址是172.194.72.105。于是，我們知道了對方的IP地址。

image.png

image.png

互聯(lián)網(wǎng)協(xié)議入門
關(guān)于 TCP/IP，必知必會的10個問題

推薦文章：
HTTP緩存機制 & cookie/localStorage/sessionStorage
前端開發(fā)之走進Vue.js(入門知識點)
《你不知道的javascript上卷》摘要(上)
《你不知道的javascript上卷》摘要(下)
Git使用總結(jié)
如何在Vue+Webpack下配置Stylelint
Highchart屬性筆記

原文：前端須知的網(wǎng)絡(luò)知識(TCP/UDP/HTTP/HTTPS...)