八股目錄

HTTP

• 1、協(xié)議參數(shù)
  HTTP 是什么？
  HTTP 常見的狀態(tài)碼有哪些？
  HTTP 常見字段有哪些？
  GET 和 POST 有什么區(qū)別？
  GET 和 POST 方法都是安全和冪等的嗎？
  HTTP 緩存有哪些實現(xiàn)方式？
  什么是強制緩存？
  什么是協(xié)商緩存？

• 2、HTTP版本特性
  HTTP/1.1 的優(yōu)點有哪些？
  HTTP/1.1 的缺點有哪些？
  HTTP/1.1 的性能如何？
  HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
  HTTP/2 做了什么優(yōu)化？
  HTTP/3 做了哪些優(yōu)化？
  HTTP/1.1 如何優(yōu)化？
  HTTP/2 牛逼在哪？
  HTTP/3 強勢來襲

• 3、其他協(xié)議
  HTTP 與 HTTPS 有哪些區(qū)別？
  HTTPS 解決了 HTTP 的哪些問題？
  HTTPS 是如何建立連接的？其間交互了什么？
  HTTPS 的應(yīng)用數(shù)據(jù)是如何保證完整性的？
  HTTPS 一定安全可靠嗎？
  HTTPS RSA 握手解析
  HTTPS ECDHE 握手解析
  HTTPS 如何優(yōu)化？
  既然有 HTTP 協(xié)議，為什么還要有 RPC？
  既然有 HTTP 協(xié)議，為什么還要有 WebSocket？

TCP

• 1、連接管理：
  tcp/udp，3握手4揮手，Socket
  3次握手（2次，4次，序列號，1-3丟失）
  4次揮手（2MSL，1-4丟失，time_wait時間，功能，過多過少，優(yōu)化，CLOSE_WAIT原因，keepalive）
  Socket（流程，listen，accept，close）
  TCP 三次握手與四次揮手面試題
  TCP 實戰(zhàn)抓包分析
  TCP 半連接隊列和全連接隊列
  如何理解是 TCP 面向字節(jié)流協(xié)議？（對比UDP）
  為什么 TCP 每次建立連接時，初始化序列號都要不一樣呢？
  HTTPS 中 TLS 和 TCP 能同時握手嗎？
  TCP Keepalive 和 HTTP Keep-Alive 是一個東西嗎？
  TCP 有什么缺陷？
  服務(wù)端沒有 listen，客戶端發(fā)起連接建立，會發(fā)生什么？
  沒有 accpet，可以建立 TCP 連接嗎？

• 2、可靠傳輸
  SYN 報文什么時候情況下會被丟棄？
  四次揮手中收到亂序的 FIN 包會如何處理？
  在 TIME_WAIT 狀態(tài)的 TCP 連接，收到 SYN 后會發(fā)生什么？
  tcp_tw_reuse 為什么默認是關(guān)閉的？
  如何基于 UDP 協(xié)議實現(xiàn)可靠傳輸？
  TCP 和 UDP 可以使用同一個端口嗎？
  TCP 連接，一端斷電和進程崩潰有什么區(qū)別？
  拔掉網(wǎng)線后， 原本的 TCP 連接還存在嗎？
  用了 TCP 協(xié)議，數(shù)據(jù)一定不會丟嗎？
  TCP 四次揮手，可以變成三次嗎？
  TCP 序列號和確認號是如何變化的？

• 3、滑動窗口，流量控制，擁塞控制
  TCP 重傳、滑動窗口、流量控制、擁塞控制
  如何優(yōu)化 TCP?（連接建立，數(shù)據(jù)傳輸）

目錄

眾所周知，OSI考研大概是有5層。
然后八股只考應(yīng)用層的HTTP和傳輸層的TCP。
即資源子網(wǎng)和與傳輸層。
或者說端到端的部分。

1、應(yīng)用層 & HTTP

一些http題

get/post（
get是獲取指定資源，post是上傳資源并對上傳的資源請求做出響應(yīng)
）

http和https（
在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程。HTTPS 默認端口號是 443，要申請證書。
）

http 301 302 404 501 502 503（
3xx重定向&永久臨時，4xx客戶端錯&資源不存在，
5xx服務(wù)器錯&未開業(yè)&代理錯&網(wǎng)絡(luò)忙
）

瀏覽器輸入url冪等性（
GET 方法是安全、冪等、可被緩存的，post是不安全不冪等的
）

session cookie 區(qū)別 什么時候都要使用（
cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙，考慮到安全應(yīng)當使用session。
session會在一定時間內(nèi)保存在服務(wù)器上。 當訪問增多，會比較占用你服務(wù)器的性能，考慮到減輕服務(wù)器性能方面，應(yīng)當使用cookie。
）

泛洪攻擊（
一種拒絕服務(wù)(DDoS) 攻擊，旨在耗盡可用服務(wù)器資源，致使服務(wù)器無法傳輸合法流量。
通過重復(fù)發(fā)送初始連接請求(SYN) 數(shù)據(jù)包，攻擊者將可擊垮目標服務(wù)器計算機上的所有可用端口，導(dǎo)致目標設(shè)備在響應(yīng)合法流量時表現(xiàn)遲鈍乃至全無響應(yīng)。
）

瀏覽器輸入Url發(fā)生了什么？
Http請求包是怎么接收的？
socket編程有了解過嗎？
服務(wù)器端要實現(xiàn)一個socket 你覺得應(yīng)該怎么實現(xiàn)？

怎么加快輸入頁面到瀏覽器顯示？
服務(wù)器做緩存（重點）
dns解析過程中可以將url解析結(jié)果中的host文件去找，
然后HTTP的協(xié)議版本不同對 頁面的請求速度也有影響（HTTP2.0是幀的請求格式，然后可以實現(xiàn)在一個TCP連接上進行多個HTTP請求）

服務(wù)器端用緩存怎么用？
用什么數(shù)據(jù)結(jié)構(gòu) LRU

我要實現(xiàn)一個功能跟函數(shù)，給你一塊內(nèi)存 如何去設(shè)置它的內(nèi)存管理跟分配

HTTPS 加密原理（問過）

• HTTP 有以下安全性問題：
  使用明文進行通信，內(nèi)容可能會被竊聽
  不驗證通信方的身份，通信方的身份有可能遭遇偽裝；
  無法證明報文的完整性，報文有可能遭篡改。
  HTTPS 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是說 HTTPS 使用了隧道進行通信。

通過使用 SSL，HTTPS 具有了加密（防竊聽）、認證（防偽裝）和完整性保護（防篡改）。

1. 對稱密鑰加密
   對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。
   優(yōu)點：運算速度快；
   缺點：無法安全地將密鑰傳輸給通信方。

2. 非對稱密鑰加密
   非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不同的密鑰。
   公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。
   非對稱密鑰除了用來加密，還可以用來進行簽名。因為私有密鑰無法被其他人獲取，因此通信發(fā)送方使用其私有密鑰進行簽名，通信接收方使用發(fā)送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。
   優(yōu)點：可以更安全地將公開密鑰傳輸給通信發(fā)送方；
   缺點：運算速度慢。

3. HTTPS 采用的加密方式
   上面提到對稱密鑰加密方式的傳輸效率更高，但是無法安全地將密鑰 Secret Key 傳輸給通信方。而非對稱密鑰加密方式可以保證傳輸?shù)陌踩?，因此我們可以利用非對稱密鑰加密方式將 Secret Key 傳輸給通信方。
   HTTPS 采用混合的加密機制，正是利用了上面提到的方案：
   使用非對稱密鑰加密方式，傳輸對稱密鑰加密方式所需要的 Secret Key，從而保證安全性;
   獲取到 Secret Key 后，再使用對稱密鑰加密方式進行通信，從而保證效率。

認證

• 通過使用 證書 來對通信方進行認證。
• 數(shù)字證書認證機構(gòu)（CA，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機構(gòu)。
• 服務(wù)器的運營人員向 CA 提出公開密鑰的申請，CA 在判明提出申請者的身份之后，會對已申請的公開密鑰做數(shù)字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起。
• 進行 HTTPS 通信時，服務(wù)器會把證書發(fā)送給客戶端?？蛻舳巳〉闷渲械墓_密鑰之后，先使用數(shù)字簽名進行驗證，如果驗證通過，就可以開始通信了。

完整性保護

• SSL 提供報文摘要功能來進行完整性保護。
• HTTP 也提供了 MD5 報文摘要功能，但不是安全的。例如報文內(nèi)容被篡改之后，同時重新計算 MD5 的值，通信接收方是無法意識到發(fā)生了篡改。
• HTTPS 的報文摘要功能之所以安全，是因為它結(jié)合了加密和認證這兩個操作。試想一下，加密之后的報文，遭到篡改之后，也很難重新計算報文摘要，因為無法輕易獲取明文。

HTTPS 的缺點

• 因為需要進行加密解密等過程，因此速度會更慢；
• 需要支付證書授權(quán)的高額費用。

HTTP/1.1 新特性

詳細內(nèi)容請見上文

默認是長連接
支持流水線
支持同時打開多個 TCP 連接
支持虛擬主機
新增狀態(tài)碼 100
支持分塊傳輸編碼
新增緩存處理指令 max-age

HTTP/2.0 與 RPC（問過）

HTTP/1.x 缺陷
HTTP/1.x 實現(xiàn)簡單是以犧牲性能為代價的：
客戶端需要使用多個連接才能實現(xiàn)并發(fā)和縮短延遲；
不會壓縮請求和響應(yīng)首部，從而導(dǎo)致不必要的網(wǎng)絡(luò)流量；
不支持有效的資源優(yōu)先級，致使底層 TCP 連接的利用率低下。

GET 和 POST 比較

GET 用于獲取資源，而 POST 用于傳輸實體主體。

GET 和 POST 的請求都能使用額外的參數(shù)，
但是 GET 的參數(shù)是以查詢字符串出現(xiàn)在 URL 中，
而 POST 的參數(shù)存儲在實體主體中。
不能因為 POST 參數(shù)存儲在實體主體中就認為它的安全性更高，因為照樣可以通過一些抓包工具（Fiddler）查看。

安全性

• 安全的 HTTP 方法不會改變服務(wù)器狀態(tài)，也就是說它只是可讀的。
• GET 方法是安全的，而 POST 卻不是，因為 POST 的目的是傳送實體主體內(nèi)容，這個內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個數(shù)據(jù)存儲到數(shù)據(jù)庫中，因此狀態(tài)也就發(fā)生了改變。
• 安全的方法除了 GET 之外還有：HEAD、OPTIONS。
• 不安全的方法除了 POST 之外還有 PUT、DELETE。

冪等性

• 冪等的 HTTP 方法，同樣的請求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。
• 換句話說就是，冪等方法不應(yīng)該具有副作用（統(tǒng)計用途除外）。
• 所有的安全方法也都是冪等的。
• 在正確實現(xiàn)的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。
• GET /pageX HTTP/1.1 是冪等的，連續(xù)調(diào)用多次，客戶端接收到的結(jié)果都是一樣的：

可緩存

• 如果要對響應(yīng)進行緩存，需要滿足以下條件：
• 請求報文的 HTTP 方法本身是可緩存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可緩存，POST 在多數(shù)情況下不可緩存的。
• 響應(yīng)報文的狀態(tài)碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
• 響應(yīng)報文的 Cache-Control 首部字段沒有指定不進行緩存。

2、傳輸層 & TCP

TCP三次握手 & 四次揮手（問過）

TCP三次握手（ 為什么不是四次，最后一次可以附數(shù)據(jù)）
TCP四次揮手（最后waittime了解嗎）

1. TCP三次握手（Three-Way Handshake）：

   • 第一次握手（SYN）：客戶端發(fā)送一個帶有SYN（同步序列號）標志位的TCP報文段給服務(wù)器，請求建立連接。
   • 第二次握手（SYN+ACK）：服務(wù)器收到客戶端的請求后，回復(fù)一個帶有SYN/ACK標志位的TCP報文段，表示同意建立連接。
   • 第三次握手（ACK）：客戶端收到服務(wù)器的回復(fù)后，再發(fā)送一個帶有ACK標志位的TCP報文段給服務(wù)器，確認連接建立。

2. TCP四次揮手（Four-Way Handshake）：

   • 第一次揮手（FIN）：當客戶端決定關(guān)閉連接時，發(fā)送一個帶有FIN（結(jié)束）標志位的TCP報文段給服務(wù)器，表示客戶端不再發(fā)送數(shù)據(jù)。
   • 第二次揮手（ACK）：服務(wù)器接收到客戶端的FIN后，發(fā)送一個帶有ACK標志位的TCP報文段給客戶端，表示已收到客戶端的關(guān)閉請求。
   • 第三次揮手（FIN）：服務(wù)器確定準備關(guān)閉連接時，發(fā)送一個帶有FIN標志位的TCP報文段給客戶端，表示服務(wù)器不再發(fā)送數(shù)據(jù)。
   • 第四次揮手（ACK）：**客戶端接收到服務(wù)器的FIN后，發(fā)送一個帶有ACK標志位的TCP報文段給服務(wù)器，**確認收到服務(wù)器的關(guān)閉請求。

為什么要四次揮手而不是三次揮手呢？

• 這是因為在關(guān)閉連接時，客戶端和服務(wù)器都可能還有未發(fā)送完的數(shù)據(jù)，需要確保對方接收完畢后才能安全地關(guān)閉連接。
• 四次揮手過程中，最后一次揮手（第四次揮手）的ACK報文段是用來確認服務(wù)器的關(guān)閉請求已經(jīng)被客戶端接收到，而不是用來傳輸數(shù)據(jù)的，以確保雙方都知道對方已經(jīng)關(guān)閉了連接。
• 簡單來說，四次揮手是為了保證雙方都能安全地關(guān)閉連接并確認對方的關(guān)閉請求已被接收。

為什么要等待2MSL？參考

• MSL是報文最大生存時間，他是任何報文在網(wǎng)絡(luò)上存活的最長時間，超過這個時間報文將被丟棄。

• 客戶端發(fā)完ACK等待2MSL，防止丟包。
  這種情況下，那服務(wù)器會一直收不到客戶端的回應(yīng)，所以這種情況是和只進行三次揮手的情況類似的，服務(wù)器沒有收到回應(yīng)，服務(wù)器就無法知道到底客戶端有沒有收到服務(wù)器斷開的請求。

• 如果客戶端收到了，那還好，皆大歡喜客戶端和服務(wù)器端都斷開連接;如果客戶端沒有收到，客戶端還一直傻傻地在那里等著服務(wù)器繼續(xù)發(fā)送消息。
  服務(wù)器無法判斷客戶端是否收到，這種情況本身就是一種不可靠的情況，堂堂號稱可靠的TCP的連接出現(xiàn)這種情況豈不是要被笑掉大牙？

• 也因此出現(xiàn)了客戶端要等待2MSL的情況。為了保證客戶端最后一次揮手的報文能夠到達服務(wù)器，如果第四次揮手的報文段丟失了，！

• 服務(wù)器會超時重傳這個第三次揮手的報文段?。。。。?！

• 所以客戶端不是直接進入CLOSED，而是要保持TIME_WAIT（等待2MSL就是TIME_WAIT）就起到作用了?。?！，

• 當再次收到服務(wù)器的超時重傳的斷開連接的第三次揮手的請求的時候，客戶端會繼續(xù)給服務(wù)器發(fā)送一個第四次揮手的報文，！

• 能夠保證對方（服務(wù)器）收到客戶端的回應(yīng)報文，最后客戶端和服務(wù)器正確的關(guān)閉連接。！

• 等待2MSL是為了保證包都過期了，防止下次建立連接的時候再出現(xiàn)，然后混淆。

為什么不是兩次或四次？

• 「兩次握手」：無法防止歷史連接的建立，會造成雙方資源的浪費，也無法可靠的同步雙方序列號；
  「四次握手」：三次握手就已經(jīng)理論上最少可靠連接建立，中間的兩次握手可以合并，所以不需要使用更多的通信次數(shù)。 最后第三次握手可以攜帶數(shù)據(jù)。

為什么每次TCP 連接時，始化的序列號都要求不一樣呢？

主要原因有兩個方面：

• 為了防止歷史報文被下一個相同四元組的連接接收（主要方面）；
• 為了安全性，防止黑客偽造的相同序列號的 TCP 報文被對方接收；

接下來，詳細說說第一點。

• 假設(shè)每次建立連接，客戶端和服務(wù)端的初始化序列號都是從 0 開始：
  客戶端和服務(wù)端建立一個 TCP 連接，在客戶端發(fā)送數(shù)據(jù)包被網(wǎng)絡(luò)阻塞了，然后超時重傳了這個數(shù)據(jù)包，而此時服務(wù)端設(shè)備斷電重啟了，之前與客戶端建立的連接就消失了，于是在收到客戶端的數(shù)據(jù)包的時候就會發(fā)送 RST 報文。
  緊接著，客戶端又與服務(wù)端建立了與上一個連接相同四元組的連接；
  在新連接建立完成后，上一個連接中被網(wǎng)絡(luò)阻塞的數(shù)據(jù)包正好抵達了服務(wù)端，剛好該數(shù)據(jù)包的序列號正好是在服務(wù)端的接收窗口內(nèi)，所以該數(shù)據(jù)包會被服務(wù)端正常接收，就會造成數(shù)據(jù)錯亂。
• 可以看到，如果每次建立連接，客戶端和服務(wù)端的初始化序列號都是一樣的話，很容易出現(xiàn)歷史報文被下一個相同四元組的連接接收的問題。
• 所以，每次初始化序列號不一樣很大程度上能夠避免歷史報文被下一個相同四元組的連接接收，注意是很大程度上，并不是完全避免了（因為序列號會有回繞的問題，所以需要用時間戳的機制來判斷歷史報文，）

初始序列號 ISN 是如何隨機產(chǎn)生的？

起始 ISN 是基于時鐘的，每 4 微秒 + 1，轉(zhuǎn)一圈要 4.55 個小時。

RFC793 提到初始化序列號 ISN 隨機生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

M 是一個計時器，這個計時器每隔 4 微秒加 1。
F 是一個 Hash 算法，根據(jù)源 IP、目的 IP、源端口、目的端口生成一個隨機數(shù)值。要保證 Hash 算法不能被外部輕易推算得出，用 MD5 算法是一個比較好的選擇。
可以看到，隨機數(shù)是會基于時鐘計時器遞增的，基本不可能會隨機成一樣的初始化序列號。

第1-3次握手丟失？

第一次

• 當客戶端超時重傳 3 次 SYN 報文后，由于 tcp_syn_retries 為 3，已達到最大重傳次數(shù)，于是再等待一段時間（時間為上一次超時時間的 2 倍），如果還是沒能收到服務(wù)端的第二次握手（SYN-ACK 報文），那么客戶端就會斷開連接。

第二次

• 因為第二次握手報文里是包含對客戶端的第一次握手的 ACK 確認報文，所以，如果客戶端遲遲沒有收到第二次握手，那么客戶端就覺得可能自己的 SYN 報文（第一次握手）丟失了，于是客戶端就會觸發(fā)超時重傳機制，重傳 SYN 報文。
• 然后，因為第二次握手中包含服務(wù)端的 SYN 報文，所以當客戶端收到后，需要給服務(wù)端發(fā)送 ACK 確認報文（第三次握手），服務(wù)端才會認為該 SYN 報文被客戶端收到了。
• 那么，如果第二次握手丟失了，服務(wù)端就收不到第三次握手，于是服務(wù)端這邊會觸發(fā)超時重傳機制，重傳 SYN-ACK 報文。
• 因此，當?shù)诙挝帐謥G失了，客戶端和服務(wù)端都會重傳：
  客戶端會重傳 SYN 報文，也就是第一次握手，最大重傳次數(shù)由 tcp_syn_retries內(nèi)核參數(shù)決定；
  服務(wù)端會重傳 SYN-ACK 報文，也就是第二次握手，最大重傳次數(shù)由 tcp_synack_retries 內(nèi)核參數(shù)決定。
• 具體過程：
• • 當客戶端超時重傳 1 次 SYN 報文后，由于 tcp_syn_retries 為 1，已達到最大重傳次數(shù)，于是再等待一段時間（時間為上一次超時時間的 2 倍），如果還是沒能收到服務(wù)端的第二次握手（SYN-ACK 報文），那么客戶端就會斷開連接。
• • 當服務(wù)端超時重傳 2 次 SYN-ACK 報文后，由于 tcp_synack_retries 為 2，已達到最大重傳次數(shù)，于是再等待一段時間（時間為上一次超時時間的 2 倍），如果還是沒能收到客戶端的第三次握手（ACK 報文），那么服務(wù)端就會斷開連接。

第三次

• 因為這個第三次握手的 ACK 是對第二次握手的 SYN 的確認報文，所以當?shù)谌挝帐謥G失了，如果服務(wù)端那一方遲遲收不到這個確認報文，就會觸發(fā)超時重傳機制，重傳 SYN-ACK 報文，直到收到第三次握手，或者達到最大重傳次數(shù)。
• 注意，ACK 報文是不會有重傳的，當 ACK 丟失了，就由對方重傳對應(yīng)的報文。
• 當服務(wù)端超時重傳 2 次 SYN-ACK 報文后，由于 tcp_synack_retries 為 2，已達到最大重傳次數(shù)，于是再等待一段時間（時間為上一次超時時間的 2 倍），如果還是沒能收到客戶端的第三次握手（ACK 報文），那么服務(wù)端就會斷開連接。

針對 TCP 應(yīng)該如何 Socket 編程？

服務(wù)端和客戶端初始化 socket，得到文件描述符；
服務(wù)端調(diào)用 bind，將 socket 綁定在指定的 IP 地址和端口;
服務(wù)端調(diào)用 listen，進行監(jiān)聽；
服務(wù)端調(diào)用 accept，等待客戶端連接；
客戶端調(diào)用 connect，向服務(wù)端的地址和端口發(fā)起連接請求；
服務(wù)端 accept 返回用于傳輸?shù)?socket 的文件描述符；
客戶端調(diào)用 write 寫入數(shù)據(jù)；服務(wù)端調(diào)用 read 讀取數(shù)據(jù)；
客戶端斷開連接時，會調(diào)用 close，那么服務(wù)端 read 讀取數(shù)據(jù)的時候，就會讀取到了 EOF，待處理完數(shù)據(jù)后，服務(wù)端調(diào)用 close，表示連接關(guān)閉。
這里需要注意的是，服務(wù)端調(diào)用 accept 時，連接成功了會返回一個已完成連接的 socket，后續(xù)用來傳輸數(shù)據(jù)。

所以，監(jiān)聽的 socket 和真正用來傳送數(shù)據(jù)的 socket，是「兩個」 socket，一個叫作監(jiān)聽 socket，一個叫作已完成連接 socket。

成功連接建立之后，雙方開始通過 read 和 write 函數(shù)來讀寫數(shù)據(jù)，就像往一個文件流里面寫東西一樣。

沒有 accept，能建立 TCP 連接嗎？

• 答案：可以的。
• accpet 系統(tǒng)調(diào)用并不參與 TCP 三次握手過程，它只是負責(zé)從 TCP 全連接隊列取出一個已經(jīng)建立連接的 socket，用戶層通過 accpet 系統(tǒng)調(diào)用拿到了已經(jīng)建立連接的 socket，就可以對該 socket 進行讀寫操作了。

沒有 listen，能建立 TCP 連接嗎？

• 答案：可以的。
• 客戶端是可以自己連自己的形成連接（TCP自連接），也可以兩個客戶端同時向?qū)Ψ桨l(fā)出請求建立連接（TCP同時打開），這兩個情況都有個共同點，就是沒有服務(wù)端參與，也就是沒有 listen，就能 TCP 建立連接。

實現(xiàn)一個TCP應(yīng)用，socket等待&綁定等過程（問過）

TCP（傳輸控制協(xié)議）是一種面向連接的、可靠的傳輸層協(xié)議，用于在網(wǎng)絡(luò)上可靠地傳輸數(shù)據(jù)。下面是TCP應(yīng)用的基本過程和相關(guān)原理的簡要說明：

1. 創(chuàng)建套接字（Socket）：TCP應(yīng)用程序首先需要創(chuàng)建一個套接字，套接字是網(wǎng)絡(luò)通信的端點。套接字可以通過調(diào)用操作系統(tǒng)提供的socket函數(shù)來創(chuàng)建，該函數(shù)返回一個唯一標識套接字的文件描述符。
2. 綁定套接字：在使用套接字之前，需要將其綁定到本地地址和端口上。這樣，其他應(yīng)用程序就可以通過指定該地址和端口來與該套接字進行通信。綁定操作可以使用bind函數(shù)來完成。
3. 監(jiān)聽連接請求：如果應(yīng)用程序作為服務(wù)器，需要監(jiān)聽傳入的連接請求。通過調(diào)用listen函數(shù)，將套接字設(shè)置為監(jiān)聽模式，并指定能夠排隊等待處理的連接請求的最大數(shù)量。
4. 接受連接請求：一旦有客戶端發(fā)起連接請求，服務(wù)器就需要接受該請求。通過調(diào)用accept函數(shù)，服務(wù)器會阻塞等待，直到有客戶端連接成功。accept函數(shù)返回一個新的套接字，該套接字用于與客戶端進行通信。
5. 進行數(shù)據(jù)傳輸：一旦建立了連接，服務(wù)器和客戶端之間就可以進行數(shù)據(jù)的傳輸。應(yīng)用程序可以使用發(fā)送（send）和接收（receive）函數(shù)來發(fā)送和接收數(shù)據(jù)。TCP協(xié)議會確保數(shù)據(jù)的可靠傳輸，包括數(shù)據(jù)分割、重組、流量控制和擁塞控制等機制。
6. 關(guān)閉連接：當數(shù)據(jù)傳輸完成或需要關(guān)閉連接時，可以調(diào)用close函數(shù)來關(guān)閉套接字。關(guān)閉連接時，TCP協(xié)議會執(zhí)行四次揮手過程，確保雙方都完成了數(shù)據(jù)的傳輸并同意關(guān)閉連接。

3、Socket = http+tcp

I/O 模型

一個輸入操作通常包括兩個階段：

• 等待數(shù)據(jù)準備好
• 從內(nèi)核向進程復(fù)制數(shù)據(jù)

對于一個套接字上的輸入操作，

• 第一步通常涉及等待數(shù)據(jù)從網(wǎng)絡(luò)中到達。當所等待數(shù)據(jù)到達時，它被復(fù)制到內(nèi)核中的某個緩沖區(qū)
• 第二步就是把數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進程緩沖區(qū)

Unix 有五種 I/O 模型：
阻塞式 I/O
非阻塞式 I/O
I/O 復(fù)用（select 和 poll）
信號驅(qū)動式 I/O（SIGIO）
異步 I/O（AIO）

阻塞式 I/O

• 應(yīng)用進程被阻塞，直到數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進程緩沖區(qū)中才返回。
  應(yīng)該注意到，在阻塞的過程中，其它應(yīng)用進程還可以執(zhí)行，因此阻塞不意味著整個操作系統(tǒng)都被阻塞。因為其它應(yīng)用進程還可以執(zhí)行，所以不消耗 CPU 時間，這種模型的 CPU 利用率會比較高。
  下圖中，recvfrom() 用于接收 Socket 傳來的數(shù)據(jù)，并復(fù)制到應(yīng)用進程的緩沖區(qū) buf 中。這里把 recvfrom() 當成系統(tǒng)調(diào)用。

非阻塞式 I/O

• 應(yīng)用進程執(zhí)行系統(tǒng)調(diào)用之后，內(nèi)核返回一個錯誤碼。應(yīng)用進程可以繼續(xù)執(zhí)行，但是需要不斷的執(zhí)行系統(tǒng)調(diào)用來獲知 I/O 是否完成，這種方式稱為輪詢（polling）。
  由于 CPU 要處理更多的系統(tǒng)調(diào)用，因此這種模型的 CPU 利用率比較低。

I/O 復(fù)用

• 使用 select 或者 poll 等待數(shù)據(jù)，并且可以等待多個套接字中的任何一個變?yōu)榭勺x。這一過程會被阻塞，當某一個套接字可讀時返回，之后再使用 recvfrom 把數(shù)據(jù)從內(nèi)核復(fù)制到進程中。
• 它可以讓單個進程具有處理多個 I/O 事件的能力。又被稱為 Event Driven I/O，即事件驅(qū)動 I/O。
• 如果一個 Web 服務(wù)器沒有 I/O 復(fù)用，那么每一個 Socket 連接都需要創(chuàng)建一個線程去處理。如果同時有幾萬個連接，那么就需要創(chuàng)建相同數(shù)量的線程。相比于多進程和多線程技術(shù)，I/O 復(fù)用不需要進程線程創(chuàng)建和切換的開銷，系統(tǒng)開銷更小。

信號驅(qū)動 I/O

• 應(yīng)用進程使用 sigaction 系統(tǒng)調(diào)用，內(nèi)核立即返回，應(yīng)用進程可以繼續(xù)執(zhí)行，也就是說等待數(shù)據(jù)階段應(yīng)用進程是非阻塞的。內(nèi)核在數(shù)據(jù)到達時向應(yīng)用進程發(fā)送 SIGIO 信號，應(yīng)用進程收到之后在信號處理程序中調(diào)用 recvfrom 將數(shù)據(jù)從內(nèi)核復(fù)制到應(yīng)用進程中。
• 相比于非阻塞式 I/O 的輪詢方式，信號驅(qū)動 I/O 的 CPU 利用率更高。

異步 I/O

• 應(yīng)用進程執(zhí)行 aio_read 系統(tǒng)調(diào)用會立即返回，應(yīng)用進程可以繼續(xù)執(zhí)行，不會被阻塞，內(nèi)核會在所有操作完成之后向應(yīng)用進程發(fā)送信號。
• 異步 I/O 與信號驅(qū)動 I/O 的區(qū)別在于，異步 I/O 的信號是通知應(yīng)用進程 I/O 完成，而信號驅(qū)動 I/O 的信號是通知應(yīng)用進程可以開始 I/O。

五大 I/O 模型比較

• 同步 I/O：將數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到應(yīng)用進程緩沖區(qū)的階段（第二階段），應(yīng)用進程會阻塞。
• 異步 I/O：第二階段應(yīng)用進程不會阻塞。
• 同步 I/O 包括阻塞式 I/O、非阻塞式 I/O、I/O 復(fù)用和信號驅(qū)動 I/O ，它們的主要區(qū)別在第一個階段。
• 非阻塞式 I/O 、信號驅(qū)動 I/O 和異步 I/O 在第一階段不會阻塞。

I/O 復(fù)用

select/poll/epoll 都是 I/O 多路復(fù)用的具體實現(xiàn)，select 出現(xiàn)的最早，之后是 poll，再是 epoll。

select

• select 允許應(yīng)用程序監(jiān)視一組文件描述符，等待一個或者多個描述符成為就緒狀態(tài)，從而完成 I/O 操作。
• fd_set 使用數(shù)組實現(xiàn)，數(shù)組大小使用 FD_SETSIZE 定義，所以只能監(jiān)聽少于 FD_SETSIZE 數(shù)量的描述符。有三種類型的描述符類型：readset、writeset、exceptset，分別對應(yīng)讀、寫、異常條件的描述符集合。
• timeout 為超時參數(shù)，調(diào)用 select 會一直阻塞直到有描述符的事件到達或者等待的時間超過 timeout。
• 成功調(diào)用返回結(jié)果大于 0，出錯返回結(jié)果為 -1，超時返回結(jié)果為 0。

poll

• poll 的功能與 select 類似，也是等待一組描述符中的一個成為就緒狀態(tài)。
• poll 中的描述符是 pollfd 類型的數(shù)組，pollfd 的定義如下：

比較

1. 功能
   select 和 poll 的功能基本相同，不過在一些實現(xiàn)細節(jié)上有所不同。
   select 會修改描述符，而 poll 不會；
   select 的描述符類型使用數(shù)組實現(xiàn)，F(xiàn)D_SETSIZE 大小默認為 1024，因此默認只能監(jiān)聽少于 1024 個描述符。
   如果要監(jiān)聽更多描述符的話，需要修改 FD_SETSIZE 之后重新編譯；而 poll 沒有描述符數(shù)量的限制；
   poll 提供了更多的事件類型，并且對描述符的重復(fù)利用上比 select 高。
   如果一個線程對某個描述符調(diào)用了 select 或者 poll，另一個線程關(guān)閉了該描述符，會導(dǎo)致調(diào)用結(jié)果不確定。
2. 速度
   select 和 poll 速度都比較慢，每次調(diào)用都需要將全部描述符從應(yīng)用進程緩沖區(qū)復(fù)制到內(nèi)核緩沖區(qū)。
3. 可移植性
   幾乎所有的系統(tǒng)都支持 select，但是只有比較新的系統(tǒng)支持 poll。

epoll_ctl()

• 用于向內(nèi)核注冊新的描述符或者是改變某個文件描述符的狀態(tài)。已注冊的描述符在內(nèi)核中會被維護在一棵紅黑樹上，通過回調(diào)函數(shù)內(nèi)核會將 I/O 準備好的描述符加入到一個鏈表中管理，進程調(diào)用 epoll_wait() 便可以得到事件完成的描述符。
• 從上面的描述可以看出，epoll 只需要將描述符從進程緩沖區(qū)向內(nèi)核緩沖區(qū)拷貝一次，并且進程不需要通過輪詢來獲得事件完成的描述符。
• epoll 僅適用于 Linux OS。
  epoll 比 select 和 poll 更加靈活而且沒有描述符數(shù)量限制。
• epoll 對多線程編程更有友好，一個線程調(diào)用了 epoll_wait() 另一個線程關(guān)閉了同一個描述符也不會產(chǎn)生像 select 和 poll 的不確定情況。

epoll工作模式
的描述符事件有兩種觸發(fā)模式：LT（level trigger）和 ET（edge trigger）。

1. LT 模式
   當 epoll_wait() 檢測到描述符事件到達時，將此事件通知進程，進程可以不立即處理該事件，下次調(diào)用 epoll_wait() 會再次通知進程。是默認的一種模式，并且同時支持 Blocking 和 No-Blocking。
2. ET 模式
   和 LT 模式不同的是，通知之后進程必須立即處理事件，下次再調(diào)用 epoll_wait() 時不會再得到事件到達的通知。

很大程度上減少了 epoll 事件被重復(fù)觸發(fā)的次數(shù)，因此效率要比 LT 模式高。只支持 No-Blocking，以避免由于一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務(wù)餓死。

應(yīng)用場景
很容易產(chǎn)生一種錯覺認為只要用 epoll 就可以了，select 和 poll 都已經(jīng)過時了，其實它們都有各自的使用場景。

1. select 應(yīng)用場景
   select 的 timeout 參數(shù)精度為微秒，而 poll 和 epoll 為毫秒，因此 select 更加適用于實時性要求比較高的場景，比如核反應(yīng)堆的控制。
   select 可移植性更好， 幾乎被所有主流平臺所支持。

2. poll 應(yīng)用場景
   poll 沒有最大描述符數(shù)量的限制，如果平臺支持并且對實時性要求不高，應(yīng)該使用 poll 而不是 select。

3. epoll 應(yīng)用場景
   只需要運行在 Linux 平臺上，有大量的描述符需要同時輪詢，并且這些連接最好是長連接。
   需要同時監(jiān)控小于 1000 個描述符，就沒有必要使用 epoll，因為這個應(yīng)用場景下并不能體現(xiàn) epoll 的優(yōu)勢。
   需要監(jiān)控的描述符狀態(tài)變化多，而且都是非常短暫的，也沒有必要使用 epoll。
   因為 epoll 中的所有描述符都存儲在內(nèi)核中，造成每次需要對描述符的狀態(tài)改變都需要通過 epoll_ctl() 進行系統(tǒng)調(diào)用，頻繁系統(tǒng)調(diào)用降低效率。
   并且 epoll 的描述符存儲在內(nèi)核，不容易調(diào)試。

4、應(yīng)用/傳輸層其他協(xié)議

傳輸時延的計算（by 王道）

表示層與會話層的功能（by 王道）

應(yīng)用層（by cyc）

• 域名系統(tǒng)
  DNS 是一個分布式數(shù)據(jù)庫，提供了主機名和 IP 地址之間相互轉(zhuǎn)換的服務(wù)。這里的分布式數(shù)據(jù)庫是指，每個站點只保留它自己的那部分數(shù)據(jù)。
  域名具有層次結(jié)構(gòu)，從上到下依次為：根域名、頂級域名、二級域名。
  DNS 可以使用 UDP 或者 TCP 進行傳輸，使用的端口號都為 53。大多數(shù)情況下 DNS 使用 UDP 進行傳輸，這就要求域名解析器和域名服務(wù)器都必須自己處理超時和重傳從而保證可靠性。在兩種情況下會使用 TCP 進行傳輸：
  如果返回的響應(yīng)超過的 512 字節(jié)（UDP 最大只支持 512 字節(jié)的數(shù)據(jù)）。
  區(qū)域傳送（區(qū)域傳送是主域名服務(wù)器向輔助域名服務(wù)器傳送變化的那部分數(shù)據(jù)）。

• 文件傳送協(xié)議
  FTP 使用 TCP 進行連接，它需要兩個連接來傳送一個文件：
  控制連接：服務(wù)器打開端口號 21 等待客戶端的連接，客戶端主動建立連接后，使用這個連接將客戶端的命令傳送給服務(wù)器，并傳回服務(wù)器的應(yīng)答。
  數(shù)據(jù)連接：用來傳送一個文件數(shù)據(jù)。
  根據(jù)數(shù)據(jù)連接是否是服務(wù)器端主動建立，F(xiàn)TP 有主動和被動兩種模式：
  主動模式：服務(wù)器端主動建立數(shù)據(jù)連接，其中服務(wù)器端的端口號為 20，客戶端的端口號隨機，但是必須大于 1024，因為 0~1023 是熟知端口號。
  被動模式：客戶端主動建立數(shù)據(jù)連接，其中客戶端的端口號由客戶端自己指定，服務(wù)器端的端口號隨機。
  主動模式要求客戶端開放端口號給服務(wù)器端，需要去配置客戶端的防火墻。被動模式只需要服務(wù)器端開放端口號即可，無需客戶端配置防火墻。但是被動模式會導(dǎo)致服務(wù)器端的安全性減弱，因為開放了過多的端口號。

• 動態(tài)主機配置協(xié)議
  DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的連網(wǎng)方式，用戶不再需要手動配置 IP 地址等信息。
  DHCP 配置的內(nèi)容不僅是 IP 地址，還包括子網(wǎng)掩碼、網(wǎng)關(guān) IP 地址。
  DHCP 工作過程如下：
  客戶端發(fā)送 Discover 報文，該報文的目的地址為 255.255.255.255:67，源地址為 0.0.0.0:68，被放入 UDP 中，該報文被廣播到同一個子網(wǎng)的所有主機上。如果客戶端和 DHCP 服務(wù)器不在同一個子網(wǎng)，就需要使用中繼代理。
  DHCP 服務(wù)器收到 Discover 報文之后，發(fā)送 Offer 報文給客戶端，該報文包含了客戶端所需要的信息。因為客戶端可能收到多個 DHCP 服務(wù)器提供的信息，因此客戶端需要進行選擇。
  如果客戶端選擇了某個 DHCP 服務(wù)器提供的信息，那么就發(fā)送 Request 報文給該 DHCP 服務(wù)器。
  DHCP 服務(wù)器發(fā)送 Ack 報文，表示客戶端此時可以使用提供給它的信息。

• 遠程登錄協(xié)議
  TELNET 用于登錄到遠程主機上，并且遠程主機上的輸出也會返回。
  TELNET 可以適應(yīng)許多計算機和操作系統(tǒng)的差異，例如不同操作系統(tǒng)系統(tǒng)的換行符定義。

• 電子郵件協(xié)議
  一個電子郵件系統(tǒng)由三部分組成：用戶代理、郵件服務(wù)器以及郵件協(xié)議。
  郵件協(xié)議包含發(fā)送協(xié)議和讀取協(xié)議，發(fā)送協(xié)議常用 SMTP，讀取協(xié)議常用 POP3 和 IMAP。

1. SMTP
   SMTP 只能發(fā)送 ASCII 碼，而互聯(lián)網(wǎng)郵件擴充 MIME 可以發(fā)送二進制文件。MIME 并沒有改動或者取代 SMTP，而是增加郵件主體的結(jié)構(gòu)，定義了非 ASCII 碼的編碼規(guī)則。
2. POP3
   POP3 的特點是只要用戶從服務(wù)器上讀取了郵件，就把該郵件刪除。但最新版本的 POP3 可以不刪除郵件。
3. IMAP
   IMAP 協(xié)議中客戶端和服務(wù)器上的郵件保持同步，如果不手動刪除郵件，那么服務(wù)器上的郵件也不會被刪除。IMAP 這種做法可以讓用戶隨時隨地去訪問服務(wù)器上的郵件。

• Web 頁面請求過程

1. DHCP 配置主機信息
   假設(shè)主機最開始沒有 IP 地址以及其它信息，那么就需要先使用 DHCP 來獲取。
   主機生成一個 DHCP 請求報文，并將這個報文放入具有目的端口 67 和源端口 68 的 UDP 報文段中。
   該報文段則被放入在一個具有廣播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 數(shù)據(jù)報中。
   該數(shù)據(jù)報則被放置在 MAC 幀中，該幀具有目的地址 FF:FF:FF:FF:FF:FF，將廣播到與交換機連接的所有設(shè)備。
   連接在交換機的 DHCP 服務(wù)器收到廣播幀之后，不斷地向上分解得到 IP 數(shù)據(jù)報、UDP 報文段、DHCP 請求報文，之后生成 DHCP ACK 報文，該報文包含以下信息：IP 地址、DNS 服務(wù)器的 IP 地址、默認網(wǎng)關(guān)路由器的 IP 地址和子網(wǎng)掩碼。該報文被放入 UDP 報文段中，UDP 報文段有被放入 IP 數(shù)據(jù)報中，最后放入 MAC 幀中。
   該幀的目的地址是請求主機的 MAC 地址，因為交換機具有自學(xué)習(xí)能力，之前主機發(fā)送了廣播幀之后就記錄了 MAC 地址到其轉(zhuǎn)發(fā)接口的交換表項，因此現(xiàn)在交換機就可以直接知道應(yīng)該向哪個接口發(fā)送該幀。
   主機收到該幀后，不斷分解得到 DHCP 報文。之后就配置它的 IP 地址、子網(wǎng)掩碼和 DNS 服務(wù)器的 IP 地址，并在其 IP 轉(zhuǎn)發(fā)表中安裝默認網(wǎng)關(guān)。

2. ARP 解析 MAC 地址
   主機通過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務(wù)器發(fā)送 HTTP 請求。為了生成該套接字，主機需要知道網(wǎng)站的域名對應(yīng)的 IP 地址。
   主機生成一個 DNS 查詢報文，該報文具有 53 號端口，因為 DNS 服務(wù)器的端口號是 53。
   該 DNS 查詢報文被放入目的地址為 DNS 服務(wù)器 IP 地址的 IP 數(shù)據(jù)報中。
   該 IP 數(shù)據(jù)報被放入一個以太網(wǎng)幀中，該幀將發(fā)送到網(wǎng)關(guān)路由器。
   DHCP 過程只知道網(wǎng)關(guān)路由器的 IP 地址，為了獲取網(wǎng)關(guān)路由器的 MAC 地址，需要使用 ARP 協(xié)議。
   主機生成一個包含目的地址為網(wǎng)關(guān)路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具有廣播目的地址（FF:FF:FF:FF:FF:FF）的以太網(wǎng)幀中，并向交換機發(fā)送該以太網(wǎng)幀，交換機將該幀轉(zhuǎn)發(fā)給所有的連接設(shè)備，包括網(wǎng)關(guān)路由器。
   網(wǎng)關(guān)路由器接收到該幀后，不斷向上分解得到 ARP 報文，發(fā)現(xiàn)其中的 IP 地址與其接口的 IP 地址匹配，因此就發(fā)送一個 ARP 回答報文，包含了它的 MAC 地址，發(fā)回給主機。

3. DNS 解析域名
   知道了網(wǎng)關(guān)路由器的 MAC 地址之后，就可以繼續(xù) DNS 的解析過程了。
   網(wǎng)關(guān)路由器接收到包含 DNS 查詢報文的以太網(wǎng)幀后，抽取出 IP 數(shù)據(jù)報，并根據(jù)轉(zhuǎn)發(fā)表決定該 IP 數(shù)據(jù)報應(yīng)該轉(zhuǎn)發(fā)的路由器。
   因為路由器具有內(nèi)部網(wǎng)關(guān)協(xié)議（RIP、OSPF）和外部網(wǎng)關(guān)協(xié)議（BGP）這兩種路由選擇協(xié)議，因此路由表中已經(jīng)配置了網(wǎng)關(guān)路由器到達 DNS 服務(wù)器的路由表項。
   到達 DNS 服務(wù)器之后，DNS 服務(wù)器抽取出 DNS 查詢報文，并在 DNS 數(shù)據(jù)庫中查找待解析的域名。
   找到 DNS 記錄之后，發(fā)送 DNS 回答報文，將該回答報文放入 UDP 報文段中，然后放入 IP 數(shù)據(jù)報中，通過路由器反向轉(zhuǎn)發(fā)回網(wǎng)關(guān)路由器，并經(jīng)過以太網(wǎng)交換機到達主機。

4. HTTP 請求頁面
   有了 HTTP 服務(wù)器的 IP 地址之后，主機就能夠生成 TCP 套接字，該套接字將用于向 Web 服務(wù)器發(fā)送 HTTP GET 報文。
   在生成 TCP 套接字之前，必須先與 HTTP 服務(wù)器進行三次握手來建立連接。生成一個具有目的端口 80 的 TCP SYN 報文段，并向 HTTP 服務(wù)器發(fā)送該報文段。
   HTTP 服務(wù)器收到該報文段之后，生成 TCP SYN ACK 報文段，發(fā)回給主機。
   連接建立之后，瀏覽器生成 HTTP GET 報文，并交付給 HTTP 服務(wù)器。
   HTTP 服務(wù)器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應(yīng)報文，將 Web 頁面內(nèi)容放入報文主體中，發(fā)回給主機。
   瀏覽器收到 HTTP 響應(yīng)報文后，抽取出 Web 頁面內(nèi)容，之后進行渲染，顯示 Web 頁面。

傳輸層（by cyc）

網(wǎng)絡(luò)層只把分組發(fā)送到目的主機，但是真正通信的并不是主機而是主機中的進程。傳輸層提供了進程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)層的核心細節(jié)，使應(yīng)用程序看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通信信道。

用戶數(shù)據(jù)報協(xié)議 UDP（User Datagram Protocol）是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對于應(yīng)用程序傳下來的報文不合并也不拆分，只是添加 UDP 首部），支持一對一、一對多、多對一和多對多的交互通信。

傳輸控制協(xié)議 TCP（Transmission Control Protocol）是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節(jié)流（把應(yīng)用層傳下來的報文看成字節(jié)流，把字節(jié)流組織成大小不等的數(shù)據(jù)塊），每一條 TCP 連接只能是點對點的（一對一）。

TCP 的三次握手
假設(shè) A 為客戶端，B 為服務(wù)器端。
首先 B 處于 LISTEN（監(jiān)聽）狀態(tài)，等待客戶的連接請求。
A 向 B 發(fā)送連接請求報文，SYN=1，ACK=0，選擇一個初始的序號 x。
B 收到連接請求報文，如果同意建立連接，則向 A 發(fā)送連接確認報文，SYN=1，ACK=1，確認號為 x+1，同時也選擇一個初始的序號 y。
A 收到 B 的連接確認報文后，還要向 B 發(fā)出確認，確認號為 y+1，序號為 x+1。
B 收到 A 的確認后，連接建立。

三次握手的原因
第三次握手是為了防止失效的連接請求到達服務(wù)器，讓服務(wù)器錯誤打開連接。
客戶端發(fā)送的連接請求如果在網(wǎng)絡(luò)中滯留，那么就會隔很長一段時間才能收到服務(wù)器端發(fā)回的連接確認。客戶端等待一個超時重傳時間之后，就會重新請求連接。但是這個滯留的連接請求最后還是會到達服務(wù)器，如果不進行三次握手，那么服務(wù)器就會打開兩個連接。
如果有第三次握手，客戶端會忽略服務(wù)器之后發(fā)送的對滯留連接請求的連接確認，不進行第三次握手，因此就不會再次打開連接。

TCP 的四次揮手
以下描述不討論序號和確認號，因為序號和確認號的規(guī)則比較簡單。并且不討論 ACK，因為 ACK 在連接建立之后都為 1。
A 發(fā)送連接釋放報文，F(xiàn)IN=1。
B 收到之后發(fā)出確認，此時 TCP 屬于半關(guān)閉狀態(tài)，B 能向 A 發(fā)送數(shù)據(jù)但是 A 不能向 B 發(fā)送數(shù)據(jù)。
當 B 不再需要連接時，發(fā)送連接釋放報文，F(xiàn)IN=1。
A 收到后發(fā)出確認，進入 TIME-WAIT 狀態(tài)，等待 2 MSL（最大報文存活時間）后釋放連接。
B 收到 A 的確認后釋放連接。

四次揮手的原因
客戶端發(fā)送了 FIN 連接釋放報文之后，服務(wù)器收到了這個報文，就進入了 CLOSE-WAIT 狀態(tài)。這個狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會發(fā)送 FIN 連接釋放報文。

TIME_WAIT
客戶端接收到服務(wù)器端的 FIN 報文后進入此狀態(tài)，此時并不是直接進入 CLOSED 狀態(tài)，還需要等待一個時間計時器設(shè)置的時間 2MSL。這么做有兩個理由：
確保最后一個確認報文能夠到達。 如果 B 沒收到 A 發(fā)送來的確認報文，那么就會重新發(fā)送連接釋放請求報文，A 等待一段時間就是為了處理這種情況的發(fā)生。
等待一段時間是為了讓本連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文都從網(wǎng)絡(luò)中消失，使得下一個新的連接不會出現(xiàn)舊的連接請求報文。

TCP 可靠傳輸

• TCP 使用超時重傳來實現(xiàn)可靠傳輸：如果一個已經(jīng)發(fā)送的報文段在超時時間內(nèi)沒有收到確認，那么就重傳這個報文段。
• 一個報文段從發(fā)送再到接收到確認所經(jīng)過的時間稱為往返時間 RTT，加權(quán)平均往返時間 RTTs

TCP 滑動窗口

• 窗口是緩存的一部分，用來暫時存放字節(jié)流。發(fā)送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發(fā)送方自己的窗口大小，發(fā)送方根據(jù)這個值和其它信息設(shè)置自己的窗口大小。
• 發(fā)送窗口內(nèi)的字節(jié)都允許被發(fā)送，接收窗口內(nèi)的字節(jié)都允許被接收。如果發(fā)送窗口左部的字節(jié)已經(jīng)發(fā)送并且收到了確認，那么就將發(fā)送窗口向右滑動一定距離，直到左部第一個字節(jié)不是已發(fā)送并且已確認的狀態(tài)；接收窗口的滑動類似，接收窗口左部字節(jié)已經(jīng)發(fā)送確認并交付主機，就向右滑動接收窗口。
• 接收窗口只會對窗口內(nèi)最后一個按序到達的字節(jié)進行確認，例如接收窗口已經(jīng)收到的字節(jié)為 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對字節(jié) 31 進行確認。發(fā)送方得到一個字節(jié)的確認之后，就知道這個字節(jié)之前的所有字節(jié)都已經(jīng)被接收。

TCP 流量控制

• 流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。
• 接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

TCP 擁塞控制

• 如果網(wǎng)絡(luò)出現(xiàn)擁塞，分組將會丟失，此時發(fā)送方會繼續(xù)重傳，從而導(dǎo)致網(wǎng)絡(luò)擁塞程度更高。因此當出現(xiàn)擁塞時，應(yīng)當控制發(fā)送方的速率。這一點和流量控制很像，但是出發(fā)點不同。
• 流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網(wǎng)絡(luò)的擁塞程度。
• TCP 主要通過四個算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復(fù)。
  發(fā)送方需要維護一個叫做擁塞窗口（cwnd）的狀態(tài)變量，注意擁塞窗口與發(fā)送方窗口的區(qū)別：擁塞窗口只是一個狀態(tài)變量，實際決定發(fā)送方能發(fā)送多少數(shù)據(jù)的是發(fā)送方窗口。
  為了便于討論，做如下假設(shè)：
  接收方有足夠大的接收緩存，因此不會發(fā)生流量控制；
  雖然 TCP 的窗口基于字節(jié)，但是這里設(shè)窗口的大小單位為報文段。

1. 慢開始與擁塞避免
   發(fā)送的最初執(zhí)行慢開始，令 cwnd = 1，發(fā)送方只能發(fā)送 1 個報文段；當收到確認后，將 cwnd 加倍，因此之后發(fā)送方能夠發(fā)送的報文段數(shù)量為：2、4、8 …
   注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非?？?，從而使得發(fā)送方發(fā)送的速度增長速度過快，網(wǎng)絡(luò)擁塞的可能性也就更高。設(shè)置一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。
   如果出現(xiàn)了超時，則令 ssthresh = cwnd / 2，然后重新執(zhí)行慢開始。

2. 快重傳與快恢復(fù)
   在接收方，要求每次接收到報文段都應(yīng)該對最后一個已收到的有序報文段進行確認。例如已經(jīng)接收到 M1 和 M2，此時收到 M4，應(yīng)當發(fā)送對 M2 的確認。
   在發(fā)送方，如果收到三個重復(fù)確認，那么可以知道下一個報文段丟失，此時執(zhí)行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。
   在這種情況下，只是丟失個別報文段，而不是網(wǎng)絡(luò)擁塞。因此執(zhí)行快恢復(fù)，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。
   慢開始和快恢復(fù)的快慢指的是 cwnd 的設(shè)定值，而不是 cwnd 的增長速率。慢開始 cwnd 設(shè)定為 1，而快恢復(fù) cwnd 設(shè)定為 ssthresh。

5、OSI（物理鏈路網(wǎng)絡(luò)）

網(wǎng)絡(luò)層IP（by 小林）

• IP 在 TCP/IP 參考模型中處于第三層，也就是網(wǎng)絡(luò)層。
• 網(wǎng)絡(luò)層的主要作用是：實現(xiàn)主機與主機之間的通信，也叫點對點（end to end）通信。

網(wǎng)絡(luò)層與數(shù)據(jù)鏈路層有什么關(guān)系呢？

• 有的小伙伴分不清 IP（網(wǎng)絡(luò)層） 和 MAC （數(shù)據(jù)鏈路層）之間的區(qū)別和關(guān)系。
• 其實很容易區(qū)分，在上面我們知道 IP 的作用是主機之間通信用的，而 MAC 的作用則是實現(xiàn)「直連」的兩個設(shè)備之間通信，而 IP 則負責(zé)在「沒有直連」的兩個網(wǎng)絡(luò)之間進行通信傳輸。
• 其實，在網(wǎng)絡(luò)中數(shù)據(jù)包傳輸中也是如此，源IP地址和目標IP地址在傳輸過程中是不會變化的（前提：沒有使用 NAT 網(wǎng)絡(luò)），只有源 MAC 地址和目標 MAC 一直在變化。

IP 地址的分類

• 互聯(lián)網(wǎng)誕生之初，IP 地址顯得很充裕，于是計算機科學(xué)家們設(shè)計了分類地址。
  IP 地址分類成了 5 種類型，分別是 A 類、B 類、C 類、D 類、E 類。
• 其中對于 A、B、C 類主要分為兩個部分，分別是網(wǎng)絡(luò)號和主機號。這很好理解，好比小林是 A 小區(qū) 1 棟 101 號，你是 B 小區(qū) 1 棟 101 號。
• A、B、C 分類地址最大主機個數(shù)是如何計算的呢？
  最大主機個數(shù)，就是要看主機號的位數(shù)，如 C 類地址的主機號占 8 位，那么 C 類地址的最大主機個數(shù)：
  主機號全為 1 指定某個網(wǎng)絡(luò)下的所有主機，用于廣播
  主機號全為 0 指定某個網(wǎng)絡(luò)

多播地址用于什么？

• 多播用于將包發(fā)送給特定組內(nèi)的所有主機。
  還是舉班級的栗子，老師說：“最后一排的同學(xué)，上來做這道數(shù)學(xué)題?！保蠋熤付ǖ氖亲詈笠慌诺耐瑢W(xué)，也就是多播的含義了。
• 由于廣播無法穿透路由，若想給其他網(wǎng)段發(fā)送同樣的包，就可以使用可以穿透路由的多播。
• 多播使用的 D 類地址，其前四位是 1110 就表示是多播地址，而剩下的 28 位是多播的組編號。
  從 224.0.0.0 ~ 239.255.255.255 都是多播的可用范圍，其劃分為以下三類：
  224.0.0.0 ~ 224.0.0.255 為預(yù)留的組播地址，只能在局域網(wǎng)中，路由器是不會進行轉(zhuǎn)發(fā)的。
  224.0.1.0 ~ 238.255.255.255 為用戶可用的組播地址，可以用于 Internet 上。
  239.0.0.0 ~ 239.255.255.255 為本地管理組播地址，可供內(nèi)部網(wǎng)在內(nèi)部使用，僅在特定的本地范圍內(nèi)有效。

IP 分類的優(yōu)點

• 不管是路由器還是主機解析到一個 IP 地址時候，我們判斷其 IP 地址的首位是否為 0，為 0 則為 A 類地址，那么就能很快的找出網(wǎng)絡(luò)地址和主機地址。
  

域名解析的工作流程
瀏覽器首先看一下自己的緩存里有沒有，如果沒有就向操作系統(tǒng)的緩存要，還沒有就檢查本機域名解析文件 hosts，如果還是沒有，就會 DNS 服務(wù)器進行查詢，查詢的過程如下：
客戶端首先會發(fā)出一個 DNS 請求，問 www.server.com 的 IP 是啥，并發(fā)給本地 DNS 服務(wù)器（也就是客戶端的 TCP/IP 設(shè)置中填寫的 DNS 服務(wù)器地址）。
本地域名服務(wù)器收到客戶端的請求后，如果緩存里的表格能找到 www.server.com，則它直接返回 IP 地址。如果沒有，本地 DNS 會去問它的根域名服務(wù)器：“老大， 能告訴我 www.server.com 的 IP 地址嗎？” 根域名服務(wù)器是最高層次的，它不直接用于域名解析，但能指明一條道路。
根 DNS 收到來自本地 DNS 的請求后，發(fā)現(xiàn)后置是 .com，說：“www.server.com 這個域名歸 .com 區(qū)域管理”，我給你 .com 頂級域名服務(wù)器地址給你，你去問問它吧。”
本地 DNS 收到頂級域名服務(wù)器的地址后，發(fā)起請求問“老二， 你能告訴我 www.server.com 的 IP 地址嗎？”
頂級域名服務(wù)器說：“我給你負責(zé) www.server.com 區(qū)域的權(quán)威 DNS 服務(wù)器的地址，你去問它應(yīng)該能問到”。
本地 DNS 于是轉(zhuǎn)向問權(quán)威 DNS 服務(wù)器：“老三，www.server.com對應(yīng)的IP是啥呀？” server.com 的權(quán)威 DNS 服務(wù)器，它是域名解析結(jié)果的原出處。為啥叫權(quán)威呢？就是我的域名我做主。
權(quán)威 DNS 服務(wù)器查詢后將對應(yīng)的 IP 地址 X.X.X.X 告訴本地 DNS。
本地 DNS 再將 IP 地址返回客戶端，客戶端和目標建立連接。
至此，我們完成了 DNS 的解析過程?，F(xiàn)在總結(jié)一下，整個過程我畫成了一個圖。

ARP

• 在傳輸一個 IP 數(shù)據(jù)報的時候，確定了源 IP 地址和目標 IP 地址后，就會通過主機「路由表」確定 IP 數(shù)據(jù)包下一跳。然而，網(wǎng)絡(luò)層的下一層是數(shù)據(jù)鏈路層，所以我們還要知道「下一跳」的 MAC 地址。
• 由于主機的路由表中可以找到下一跳的 IP 地址，所以可以通過 ARP 協(xié)議，求得下一跳的 MAC 地址。
• 那么 ARP 又是如何知道對方 MAC 地址的呢？
• 簡單地說，ARP 是借助 ARP 請求與 ARP 響應(yīng)兩種類型的包確定 MAC 地址的。
  主機會通過廣播發(fā)送 ARP 請求，這個包中包含了想要知道的 MAC 地址的主機 IP 地址。
  當同個鏈路中的所有設(shè)備收到 ARP 請求時，會去拆開 ARP 請求包里的內(nèi)容，如果 ARP 請求包中的目標 IP 地址與自己的 IP 地址一致，那么這個設(shè)備就將自己的 MAC 地址塞入 ARP 響應(yīng)包返回給主機。
  操作系統(tǒng)通常會把第一次通過 ARP 獲取的 MAC 地址緩存起來，以便下次直接從緩存中找到對應(yīng) IP 地址的 MAC 地址。

RARP 協(xié)議你知道是什么嗎？

• ARP 協(xié)議是已知 IP 地址求 MAC 地址，那 RARP 協(xié)議正好相反，它是已知 MAC 地址求 IP 地址。例如將打印機服務(wù)器等小型嵌入式設(shè)備接入到網(wǎng)絡(luò)時就經(jīng)常會用得到。
  通常這需要架設(shè)一臺 RARP 服務(wù)器，在這個服務(wù)器上注冊設(shè)備的 MAC 地址及其 IP 地址。然后再將這個設(shè)備接入到網(wǎng)絡(luò)，接著：
  該設(shè)備會發(fā)送一條「我的 MAC 地址是XXXX，請告訴我，我的IP地址應(yīng)該是什么」的請求信息。
  RARP 服務(wù)器接到這個消息后返回「MAC地址為 XXXX 的設(shè)備，IP地址為 XXXX」的信息給這個設(shè)備。
  最后，設(shè)備就根據(jù)從 RARP 服務(wù)器所收到的應(yīng)答信息設(shè)置自己的 IP 地址。

DHCP

• DHCP 在生活中我們是很常見的了，我們的電腦通常都是通過 DHCP 動態(tài)獲取 IP 地址，大大省去了配 IP 信息繁瑣的過程。
  接下來，我們來看看我們的電腦是如何通過 4 個步驟的過程，獲取到 IP 的。
  先說明一點，DHCP 客戶端進程監(jiān)聽的是 68 端口號，DHCP 服務(wù)端進程監(jiān)聽的是 67 端口號。

這 4 個步驟：

• 客戶端首先發(fā)起 DHCP 發(fā)現(xiàn)報文（DHCP DISCOVER） 的 IP 數(shù)據(jù)報，由于客戶端沒有 IP 地址，也不知道 DHCP 服務(wù)器的地址，所以使用的是 UDP 廣播通信，其使用的廣播目的地址是 255.255.255.255（端口 67） 并且使用 0.0.0.0（端口 68） 作為源 IP 地址。DHCP 客戶端將該 IP 數(shù)據(jù)報傳遞給鏈路層，鏈路層然后將幀廣播到所有的網(wǎng)絡(luò)中設(shè)備。
• DHCP 服務(wù)器收到 DHCP 發(fā)現(xiàn)報文時，用 DHCP 提供報文（DHCP OFFER） 向客戶端做出響應(yīng)。該報文仍然使用 IP 廣播地址 255.255.255.255，該報文信息攜帶服務(wù)器提供可租約的 IP 地址、子網(wǎng)掩碼、默認網(wǎng)關(guān)、DNS 服務(wù)器以及 IP 地址租用期。
• 客戶端收到一個或多個服務(wù)器的 DHCP 提供報文后，從中選擇一個服務(wù)器，并向選中的服務(wù)器發(fā)送 DHCP 請求報文（DHCP REQUEST進行響應(yīng)，回顯配置的參數(shù)。
• 最后，服務(wù)端用 DHCP ACK 報文對 DHCP 請求報文進行響應(yīng)，應(yīng)答所要求的參數(shù)。
  一旦客戶端收到 DHCP ACK 后，交互便完成了，并且客戶端能夠在租用期內(nèi)使用 DHCP 服務(wù)器分配的 IP 地址。

網(wǎng)絡(luò)層（by cyc）

路由（算法，異構(gòu)，協(xié)議，組播）+轉(zhuǎn)發(fā)（IPV4,6，移動IP）

• 因為網(wǎng)絡(luò)層是整個互聯(lián)網(wǎng)的核心，因此應(yīng)當讓網(wǎng)絡(luò)層盡可能簡單。網(wǎng)絡(luò)層向上只提供簡單靈活的、無連接的、盡最大努力交互的數(shù)據(jù)報服務(wù)。
  使用 IP 協(xié)議，可以把異構(gòu)的物理網(wǎng)絡(luò)連接起來，使得在網(wǎng)絡(luò)層看起來好像是一個統(tǒng)一的網(wǎng)絡(luò)。

• 與 IP 協(xié)議配套使用的還有三個協(xié)議：（轉(zhuǎn)發(fā)）
  地址解析協(xié)議 ARP（Address Resolution Protocol）
  網(wǎng)際控制報文協(xié)議 ICMP（Internet Control Message Protocol）
  網(wǎng)際組管理協(xié)議 IGMP（Internet Group Management Protocol）

• IP 數(shù)據(jù)報格式（轉(zhuǎn)發(fā)）
  版本 : 有 4（IPv4）和 6（IPv6）兩個值；
  首部長度 : 占 4 位，因此最大值為 15。值為 1 表示的是 1 個 32 位字的長度，也就是 4 字節(jié)。因為固定部分長度為 20 字節(jié)，因此該值最小為 5。如果可選字段的長度不是 4 字節(jié)的整數(shù)倍，就用尾部的填充部分來填充。
  區(qū)分服務(wù) : 用來獲得更好的服務(wù)，一般情況下不使用。
  總長度 : 包括首部長度和數(shù)據(jù)部分長度。
  生存時間 ：TTL，它的存在是為了防止無法交付的數(shù)據(jù)報在互聯(lián)網(wǎng)中不斷兜圈子。以路由器跳數(shù)為單位，當 TTL 為 0 時就丟棄數(shù)據(jù)報。
  協(xié)議 ：指出攜帶的數(shù)據(jù)應(yīng)該上交給哪個協(xié)議進行處理，例如 ICMP、TCP、UDP 等。
  首部檢驗和 ：因為數(shù)據(jù)報每經(jīng)過一個路由器，都要重新計算檢驗和，因此檢驗和不包含數(shù)據(jù)部分可以減少計算的工作量。
  標識 : 在數(shù)據(jù)報長度過長從而發(fā)生分片的情況下，相同數(shù)據(jù)報的不同分片具有相同的標識符。
  片偏移 : 和標識符一起，用于發(fā)生分片的情況。片偏移的單位為 8 字節(jié)。

• IP 地址編址方式（轉(zhuǎn)發(fā)）
  IP 地址的編址方式經(jīng)歷了三個歷史階段：
  分類
  子網(wǎng)劃分
  無分類

1. 分類
   由兩部分組成，網(wǎng)絡(luò)號和主機號，其中不同分類具有不同的網(wǎng)絡(luò)號長度，并且是固定的。
   IP 地址 ::= {< 網(wǎng)絡(luò)號 >, < 主機號 >}
2. 子網(wǎng)劃分
   通過在主機號字段中拿一部分作為子網(wǎng)號，把兩級 IP 地址劃分為三級 IP 地址。
   IP 地址 ::= {< 網(wǎng)絡(luò)號 >, < 子網(wǎng)號 >, < 主機號 >}
   要使用子網(wǎng)，必須配置子網(wǎng)掩碼。一個 B 類地址的默認子網(wǎng)掩碼為 255.255.0.0，如果 B 類地址的子網(wǎng)占兩個比特，那么子網(wǎng)掩碼為 11111111 11111111 11000000 00000000，也就是 255.255.192.0。
   注意，外部網(wǎng)絡(luò)看不到子網(wǎng)的存在。
3. 無分類
   無分類編址 CIDR 消除了傳統(tǒng) A 類、B 類和 C 類地址以及劃分子網(wǎng)的概念，使用網(wǎng)絡(luò)前綴和主機號來對 IP 地址進行編碼，網(wǎng)絡(luò)前綴的長度可以根據(jù)需要變化。

• 地址解析協(xié)議 ARP（轉(zhuǎn)發(fā)）
  網(wǎng)絡(luò)層實現(xiàn)主機之間的通信，而鏈路層實現(xiàn)具體每段鏈路之間的通信。因此在通信過程中，IP 數(shù)據(jù)報的源地址和目的地址始終不變，而 MAC 地址隨著鏈路的改變而改變。
  ARP 實現(xiàn)由 IP 地址得到 MAC 地址。
  每個主機都有一個 ARP 高速緩存，里面有本局域網(wǎng)上的各主機和路由器的 IP 地址到 MAC 地址的映射表。
  如果主機 A 知道主機 B 的 IP 地址，但是 ARP 高速緩存中沒有該 IP 地址到 MAC 地址的映射，此時主機 A 通過廣播的方式發(fā)送 ARP 請求分組，主機 B 收到該請求后會發(fā)送 ARP 響應(yīng)分組給主機 A 告知其 MAC 地址，隨后主機 A 向其高速緩存中寫入主機 B 的 IP 地址到 MAC 地址的映射。

• 網(wǎng)際控制報文協(xié)議 ICMP（轉(zhuǎn)發(fā)）
  ICMP 是為了更有效地轉(zhuǎn)發(fā) IP 數(shù)據(jù)報和提高交付成功的機會。它封裝在 IP 數(shù)據(jù)報中，但是不屬于高層協(xié)議。
  ICMP 報文分為差錯報告報文和詢問報文。

• 虛擬專用網(wǎng) VPN（轉(zhuǎn)發(fā)）
  由于 IP 地址的緊缺，一個機構(gòu)能申請到的 IP 地址數(shù)往往遠小于本機構(gòu)所擁有的主機數(shù)。并且一個機構(gòu)并不需要把所有的主機接入到外部的互聯(lián)網(wǎng)中，機構(gòu)內(nèi)的計算機可以使用僅在本機構(gòu)有效的 IP 地址（專用地址）。
  有三個專用地址塊：
  10.0.0.0 ~ 10.255.255.255
  172.16.0.0 ~ 172.31.255.255
  192.168.0.0 ~ 192.168.255.255
  VPN 使用公用的互聯(lián)網(wǎng)作為本機構(gòu)各專用網(wǎng)之間的通信載體。專用指機構(gòu)內(nèi)的主機只與本機構(gòu)內(nèi)的其它主機通信；虛擬指好像是，而實際上并不是，它有經(jīng)過公用的互聯(lián)網(wǎng)。
  下圖中，場所 A 和 B 的通信經(jīng)過互聯(lián)網(wǎng)，如果場所 A 的主機 X 要和另一個場所 B 的主機 Y 通信，IP 數(shù)據(jù)報的源地址是 10.1.0.1，目的地址是 10.2.0.3。數(shù)據(jù)報先發(fā)送到與互聯(lián)網(wǎng)相連的路由器 R1，R1 對內(nèi)部數(shù)據(jù)進行加密，然后重新加上數(shù)據(jù)報的首部，源地址是路由器 R1 的全球地址 125.1.2.3，目的地址是路由器 R2 的全球地址 194.4.5.6。路由器 R2 收到數(shù)據(jù)報后將數(shù)據(jù)部分進行解密，恢復(fù)原來的數(shù)據(jù)報，此時目的地址為 10.2.0.3，就交付給 Y。

• 網(wǎng)絡(luò)地址轉(zhuǎn)換 NAT（轉(zhuǎn)發(fā)）
  專用網(wǎng)內(nèi)部的主機使用本地 IP 地址又想和互聯(lián)網(wǎng)上的主機通信時，可以使用 NAT 來將本地 IP 轉(zhuǎn)換為全球 IP。
  在以前，NAT 將本地 IP 和全球 IP 一一對應(yīng)，這種方式下?lián)碛?n 個全球 IP 地址的專用網(wǎng)內(nèi)最多只可以同時有 n 臺主機接入互聯(lián)網(wǎng)。為了更有效地利用全球 IP 地址，現(xiàn)在常用的 NAT 轉(zhuǎn)換表把傳輸層的端口號也用上了，使得多個專用網(wǎng)內(nèi)部的主機共用一個全球 IP 地址。使用端口號的 NAT 也叫做網(wǎng)絡(luò)地址與端口轉(zhuǎn)換 NAPT。

• 路由器的結(jié)構(gòu)（路由）
  路由器從功能上可以劃分為：路由選擇和分組轉(zhuǎn)發(fā)。
  分組轉(zhuǎn)發(fā)結(jié)構(gòu)由三個部分組成：交換結(jié)構(gòu)、一組輸入端口和一組輸出端口。

• 路由器分組轉(zhuǎn)發(fā)流程
  從數(shù)據(jù)報的首部提取目的主機的 IP 地址 D，得到目的網(wǎng)絡(luò)地址 N。
  若 N 就是與此路由器直接相連的某個網(wǎng)絡(luò)地址，則進行直接交付；
  若路由表中有目的地址為 D 的特定主機路由，則把數(shù)據(jù)報傳送給表中所指明的下一跳路由器；
  若路由表中有到達網(wǎng)絡(luò) N 的路由，則把數(shù)據(jù)報傳送給路由表中所指明的下一跳路由器；
  若路由表中有一個默認路由，則把數(shù)據(jù)報傳送給路由表中所指明的默認路由器；
  報告轉(zhuǎn)發(fā)分組出錯。

路由選擇協(xié)議

• 路由選擇協(xié)議都是自適應(yīng)的，能隨著網(wǎng)絡(luò)通信量和拓撲結(jié)構(gòu)的變化而自適應(yīng)地進行調(diào)整。
  互聯(lián)網(wǎng)可以劃分為許多較小的自治系統(tǒng) AS，一個 AS 可以使用一種和別的 AS 不同的路由選擇協(xié)議。
  可以把路由選擇協(xié)議劃分為兩大類：
  自治系統(tǒng)內(nèi)部的路由選擇：RIP 和 OSPF
  自治系統(tǒng)間的路由選擇：BGP

數(shù)據(jù)鏈路層（by 王道）

數(shù)據(jù)鏈路層（By cyc）

基本功能

1. 封裝成幀
   將網(wǎng)絡(luò)層傳下來的分組添加首部和尾部，用于標記幀的開始和結(jié)束。
2. 透明傳輸
   透明表示一個實際存在的事物看起來好像不存在一樣。
   幀使用首部和尾部進行定界，如果幀的數(shù)據(jù)部分含有和首部尾部相同的內(nèi)容，那么幀的開始和結(jié)束位置就會被錯誤的判定。需要在數(shù)據(jù)部分出現(xiàn)首部尾部相同的內(nèi)容前面插入轉(zhuǎn)義字符。如果數(shù)據(jù)部分出現(xiàn)轉(zhuǎn)義字符，那么就在轉(zhuǎn)義字符前面再加個轉(zhuǎn)義字符。在接收端進行處理之后可以還原出原始數(shù)據(jù)。這個過程透明傳輸?shù)膬?nèi)容是轉(zhuǎn)義字符，用戶察覺不到轉(zhuǎn)義字符的存在。
3. 差錯檢測
   目前數(shù)據(jù)鏈路層廣泛使用了循環(huán)冗余檢驗（CRC）來檢查比特差錯。

信道分類

1. 廣播信道
   一對多通信，一個節(jié)點發(fā)送的數(shù)據(jù)能夠被廣播信道上所有的節(jié)點接收到。
   所有的節(jié)點都在同一個廣播信道上發(fā)送數(shù)據(jù)，因此需要有專門的控制方法進行協(xié)調(diào)，避免發(fā)生沖突（沖突也叫碰撞）。
   主要有兩種控制方法進行協(xié)調(diào)，一個是使用信道復(fù)用技術(shù)，一是使用 CSMA/CD 協(xié)議。
2. 點對點信道
   一對一通信。
   因為不會發(fā)生碰撞，因此也比較簡單，使用 PPP 協(xié)議進行控制。

信道復(fù)用技術(shù)

1. 頻分復(fù)用
   頻分復(fù)用的所有主機在相同的時間占用不同的頻率帶寬資源。
2. 時分復(fù)用
   時分復(fù)用的所有主機在不同的時間占用相同的頻率帶寬資源。
   使用頻分復(fù)用和時分復(fù)用進行通信，在通信的過程中主機會一直占用一部分信道資源。但是由于計算機數(shù)據(jù)的突發(fā)性質(zhì)，通信過程沒必要一直占用信道資源而不讓出給其它用戶使用，因此這兩種方式對信道的利用率都不高。
3. 統(tǒng)計時分復(fù)用
   是對時分復(fù)用的一種改進，不固定每個用戶在時分復(fù)用幀中的位置，只要有數(shù)據(jù)就集中起來組成統(tǒng)計時分復(fù)用幀然后發(fā)送。
4. 波分復(fù)用
   光的頻分復(fù)用。由于光的頻率很高，因此習(xí)慣上用波長而不是頻率來表示所使用的光載波。
5. 碼分復(fù)用
   為每個用戶分配 m bit 的碼片，并且所有的碼片正交，對于任意兩個碼片 和 有

CSMA/CD 協(xié)議

• CSMA/CD 表示載波監(jiān)聽多點接入 / 碰撞檢測。
• 多點接入 ：說明這是總線型網(wǎng)絡(luò)，許多主機以多點的方式連接到總線上。
• 載波監(jiān)聽 ：每個主機都必須不停地監(jiān)聽信道。在發(fā)送前，如果監(jiān)聽到信道正在使用，就必須等待。
• 碰撞檢測 ：在發(fā)送中，如果監(jiān)聽到信道已有其它主機正在發(fā)送數(shù)據(jù)，就表示發(fā)生了碰撞。雖然每個主機在發(fā)送數(shù)據(jù)之前都已經(jīng)監(jiān)聽到信道為空閑，但是由于電磁波的傳播時延的存在，還是有可能會發(fā)生碰撞。

PPP 協(xié)議

• 互聯(lián)網(wǎng)用戶通常需要連接到某個 ISP 之后才能接入到互聯(lián)網(wǎng)，PPP 協(xié)議是用戶計算機和 ISP 進行通信時所使用的數(shù)據(jù)鏈路層協(xié)議。

MAC 地址

• MAC 地址是鏈路層地址，長度為 6 字節(jié)（48 位），用于唯一標識網(wǎng)絡(luò)適配器（網(wǎng)卡）。
• 一臺主機擁有多少個網(wǎng)絡(luò)適配器就有多少個 MAC 地址。例如筆記本電腦普遍存在無線網(wǎng)絡(luò)適配器和有線網(wǎng)絡(luò)適配器，因此就有兩個 MAC 地址。

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

• 局域網(wǎng)
  局域網(wǎng)是一種典型的廣播信道，主要特點是網(wǎng)絡(luò)為一個單位所擁有，且地理范圍和站點數(shù)目均有限。
  主要有以太網(wǎng)、令牌環(huán)網(wǎng)、FDDI 和 ATM 等局域網(wǎng)技術(shù)，目前以太網(wǎng)占領(lǐng)著有線局域網(wǎng)市場。
  可以按照網(wǎng)絡(luò)拓撲結(jié)構(gòu)對局域網(wǎng)進行分類：

• 以太網(wǎng)
  以太網(wǎng)是一種星型拓撲結(jié)構(gòu)局域網(wǎng)。
  早期使用集線器進行連接，集線器是一種物理層設(shè)備， 作用于比特而不是幀，當一個比特到達接口時，集線器重新生成這個比特，并將其能量強度放大，從而擴大網(wǎng)絡(luò)的傳輸距離，之后再將這個比特發(fā)送到其它所有接口。如果集線器同時收到兩個不同接口的幀，那么就發(fā)生了碰撞。

• 虛擬局域網(wǎng)VLAN
  虛擬局域網(wǎng)可以建立與物理位置無關(guān)的邏輯組，只有在同一個虛擬局域網(wǎng)中的成員才會收到鏈路層廣播信息。
  使用 VLAN 干線連接來建立虛擬局域網(wǎng)，每臺交換機上的一個特殊接口被設(shè)置為干線接口，以互連 VLAN 交換機。IEEE 定義了一種擴展的以太網(wǎng)幀格式 802.1Q，它在標準以太網(wǎng)幀上加進了 4 字節(jié)首部 VLAN 標簽，用于表示該幀屬于哪一個虛擬局域網(wǎng)。

網(wǎng)絡(luò)設(shè)備

• 交換機
  交換機具有自學(xué)習(xí)能力，學(xué)習(xí)的是交換表的內(nèi)容，交換表中存儲著 MAC 地址到接口的映射。
  正是由于這種自學(xué)習(xí)能力，因此交換機是一種即插即用設(shè)備，不需要網(wǎng)絡(luò)管理員手動配置交換表內(nèi)容。

物理層（by cyc）

通信方式

• 根據(jù)信息在傳輸線上的傳送方向，分為以下三種通信方式：
• 單工通信：單向傳輸
• 半雙工通信：雙向交替?zhèn)鬏?/li>
• 全雙工通信：雙向同時傳輸

帶通調(diào)制文章來源地址http://www.zghlxwxcb.cn/news/detail-678824.html

• 模擬信號是連續(xù)的信號，數(shù)字信號是離散的信號。
• 帶通調(diào)制把數(shù)字信號轉(zhuǎn)換為模擬信號。

到了這里，關(guān)于【八股】2023秋招八股復(fù)習(xí)筆記5（計算機網(wǎng)絡(luò)-CN）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！