1. OSI與TCP/IP 模型
2. 常見網絡服務分層
3. TCP三向交握
4. 四次揮手過程：
5. 為什麼連接配接的時候是三次握手，關閉的時候卻是四次握手?
6. 如何檢視TIME-WAIT狀态的連結數量？
7. 為什麼會TIME-WAIT過多？解決方法是怎樣的？
8. 半連接配接，洪泛攻擊問題以及如何解決（syn_cookie）
9. 為什麼用戶端的TIME-WAIT狀态必須等待2MSL ?
10. 4g切換wifi會發生什麼
11. TCP與UDP差別及場景
12. TCP滑動視窗，擁塞控制
13. TCP粘包原因和解決方法
14. TCP、UDP封包格式
15. TCP協定如何保證可靠傳輸機制？
16. TCP的滑動視窗?
17. 詳細講一下擁塞控制? 為何要進行擁塞控制？
18. TCP擁塞控制4種算法
1. HTTP協定1.0 1.1 2.0
2. HTTP1.0和HTTP1.1的主要差別如下：
3. HTTP1.1和HTTP2.0的主要差別：
4. HTTP和 HTTPS的差別：
5. HTTPS 的缺點：
6. HTTPS連結建立的過程：
7. HTTP常見響應狀态碼
8. 狀态碼301和302的差別是什麼?
9. 對稱加密算法與非對稱加密算法的差別
10. HTTP請求方法：
11. Get和Post請求差別
12. GET 和 POST 方法都是安全和幂等的嗎？
13. 重定向和轉發差別
14. Cookie和Session差別
15. 浏覽器輸入URL過程
16. DNS協定是TCP還是UDP?
17. ARP協定如何找到對應IP位址和mac的映射的
18. RARP 協定你知道是什麼嗎？
19. 什麼是DDos攻擊?
20. 什麼是XSS攻擊?
21. SQL注入是什麼，如何避免SQL注入?
22. 網絡程式設計socket，用戶端和服務端通信過程，分别調用了哪些函數，作用是什麼
23. 負載均衡算法有哪些?

“知其然，知其是以然。最近看了《圖解HTTP》、《圖解TCPIP》、《小林coding》和謝希仁的《計算機網絡》順帶做了一點筆記。

基礎知識

1. OSI與TCP/IP 模型

OSI七層：實體層、資料鍊路層、網絡層、傳輸層、會話層、表示層、應用層

TCP/IP五層：實體層、資料鍊路層、網絡層、傳輸層、應用層

七層網絡體系結構各層的主要功能：

應用層：為應用程式提供互動服務。在網際網路中的應用層協定很多，如域名系統 DNS ，支援網際網路應用的 HTTP 協定，支援電子郵件的 SMTP 協定等。
表示層：主要負責資料格式的轉換，如加密解密、轉換翻譯、壓縮解壓縮等。
會話層：負責在網絡中的兩節點之間建立、維持和終止通信，如伺服器驗證使用者登入便是由會話層完成的。
運輸層：有時也譯為傳輸層，向主機程序提供通用的資料傳輸服務。該層主要有以下兩種協定:
- TCP ：提供面向連接配接的、可靠的資料傳輸服務;
- UDP ：提供無連接配接的、盡最大努力的資料傳輸服務，但不保證資料傳輸的可靠性。
網絡層：選擇合适的路由和交換結點，確定資料及時傳送。主要包括 IP 協定。
資料鍊路層：資料鍊路層通常簡稱為鍊路層。将網絡層傳下來的 IP 資料包組裝成幀，并再相鄰節點的鍊路上傳送幀。
實體層：實作相鄰節點間比特流的透明傳輸，盡可能屏蔽傳輸媒體和通信手段的差異。

2. 常見網絡服務分層

應用層：

HTTP

、

DNS

、

FTP

、

SMTP

傳輸層：

TCP

、

UDP

網絡層：

IP

、

ICMP

、路由器、防火牆

資料鍊路層：網卡、網橋、交換機

實體層：中繼器、集線器

3. TCP三向交握

三次握手過程：

用戶端——發送帶有 SYN 标志的資料包——服務端一次握手用戶端進入 syn_sent 狀态
服務端——發送帶有 SYN/ACK 标志的資料包——用戶端二次握手服務端進入 syn_rcvd
用戶端——發送帶有 ACK 标志的資料包——服務端三次握手連接配接就進入 Established 狀态

為什麼三次：主要是為了建立可靠的通信信道，保證用戶端與服務端同時具備發送、接收資料的能力。

為什麼兩次不行？

防止已失效的請求封包又傳送到了服務端，建立了多餘的連結，浪費資源。
兩次握手隻能保證單向連接配接是暢通的。（為了實作可靠資料傳輸， TCP 協定的通信雙方，都必須維護一個序列号，以辨別發送出去的資料包中，哪些是已經被對方收到的。三次握手的過程即是通信雙方互相告知序列号起始值，并确認對方已經收到了序列号起始值的必經步驟；如果隻是兩次握手，至多隻有連接配接發起方的起始序列号能被确認，另一方選擇的序列号則得不到确認）。

4. 四次揮手過程：

用戶端——發送帶有 FIN 标志的資料包——服務端，關閉與服務端的連接配接，用戶端進入 FIN-WAIT-1 狀态
服務端收到這個 FIN ，它發回⼀個 ACK ，确認序号為收到的序号加 1 ，服務端就進入了 CLOSE-WAIT 狀态
服務端——發送⼀個 FIN 資料包——用戶端，關閉與用戶端的連接配接，用戶端就進入 FIN-WAIT-2 狀态
用戶端收到這個 FIN ，發回 ACK 報⽂确認，并将确認序号設定為收到序号加 1 ，用戶端進入 TIME-WAIT 狀态

為什麼四次：因為需要確定用戶端與服務端的資料能夠完成傳輸。

CLOSE-WAIT：這種狀态的含義其實是表示在等待關閉。

TIME-WAIT：為了解決網絡的丢包和網絡不穩定所帶來的其他問題，確定連接配接方能在時間範圍内，關閉自己的連接配接。

5. 為什麼連接配接的時候是三次握手，關閉的時候卻是四次握手?

伺服器在收到用戶端的

FIN

封包段後，可能還有一些資料要傳輸，是以不能馬上關閉連接配接，但是會做出應答，傳回

ACK

封包段。

接下來可能會繼續發送資料，在資料發送完後，伺服器會向用戶端發送

FIN

封包，表示資料已經發送完畢，請求關閉連接配接。伺服器的

ACK

和

FIN

一般都會分開發送，進而導緻多了一次，是以一共需要四次揮手。

6. 如何檢視TIME-WAIT狀态的連結數量？

netstat -an | grep TIME_WAIT | wc -l  //檢視連接配接數等待time_wait狀态連接配接數

複制

7. 為什麼會TIME-WAIT過多？解決方法是怎樣的？

可能原因：高并發短連接配接的

TCP

伺服器上，當伺服器處理完請求後立刻按照主動正常關閉連接配接

解決：負載均衡伺服器；Web伺服器首先關閉來自負載均衡伺服器的連接配接

8. 半連接配接，洪泛攻擊問題以及如何解決（syn_cookie）

在三次握手的過程中，伺服器為了響應一個受到的

SYN

封包段，會配置設定并初始化連接配接變量和緩存，然後伺服器發送一個

SYN/ACK

封包段進行響應，并等待用戶端的

ACK

封包段。如果客戶不發送

ACK

來完成該三次握手的第三步，最終(通常在一分多鐘之後)伺服器将終止該半開連接配接并回收資源。這種

TCP

連接配接管理協定的特性就會有這樣一個漏洞，攻擊者發送大量的

TCP SYN

封包段，而不完成第三次握手的步驟。随着這種

SYN

封包段的不斷到來，伺服器不斷為這些半開連接配接配置設定資源，進而導緻伺服器連接配接資源被消耗殆盡。這種攻擊就是

SYN

泛供攻擊。

為了應對這種攻擊，現在有一種有效的防禦系統，稱為SYN cookie。SYN cookie的工作方式如下：

當伺服器接收到一個 SYN 封包段時，它并不知道該封包段是來自一個合法的使用者，還是這種SYN洪泛攻擊的一部分。因為伺服器不會為該封包段生成一個半開的連接配接。相反，伺服器生成一個初始 TCP 序列号，該序列号是SYN封包段的源IP位址和目的IP位址，源端口号和目的端口号以及僅有伺服器知道的秘密數的複雜函數(散列函數)。這種精心制作的初始序列号稱為為“cookie”。伺服器則發送具有這種特殊初始序号的 SYN/ACK 封包分組。伺服器并不記憶該cookie或任何對應于SYN的其他狀态資訊。
如果該客戶是合法的，則它将傳回一個 ACK 封包段。當伺服器收到該 ACK 封包段，需要驗證該ACK是與前面發送的某個 SYN 相對應。由于伺服器并不維護有關 SYN 封包段的記憶，是以伺服器通過使用 SYN/ACK 封包段中的源和目的IP位址與端口号以及秘密數運作相同的散列函數。如果這個函數的結果(cookie值)加1和在客戶的ACK封包段中的确認值相同的話，那麼伺服器就會認為該 ACK 對應于較早的 SYN 封包段，是以它是合法的。伺服器則會生成一個套接字的全開連接配接。
另一方面，如果客戶沒有傳回一個 ACK 封包段，說明之前的 SYN 封包段是洪泛攻擊的一部分，但是它并沒有對伺服器産生危害，因為伺服器沒有為它配置設定任何資源。

9. 為什麼用戶端的TIME-WAIT狀态必須等待2MSL ?

主要有兩個原因:

為了保證用戶端發送的最後一個ACK封包段能夠達到伺服器。這個 ACK 封包段可能丢失，因而使處在 LAST-ACK 狀态的伺服器收不到确認。伺服器會逾時重傳 FIN+ACK 封包段，用戶端就能在2MSL時間内收到這個重傳的 FIN+ACK 封包段，接着用戶端重傳一次确認，重新開機計時器。最好，用戶端和伺服器都正常進入到 CLOSED 狀态。如果用戶端在 TIME-WAIT 狀态不等待一段時間，而是再發送完 ACK 封包後立即釋放連接配接，那麼就無法收到伺服器重傳的 FIN+ACK 封包段，因而也不會再發送一次确認封包。這樣，伺服器就無法按照正常步驟進入 CLOSED 狀态。
防止已失效的連接配接請求封包段出現在本連接配接中。用戶端在發送完最後一個 ACK 确認封包段後，再經過時間 2MSL ，就可以使本連接配接持續的時間内所産生的所有封包段都從網絡中消失。這樣就可以使下一個新的連接配接中不會出現這種舊的連接配接請求封包段。

10. 4g切換wifi會發生什麼

當移動裝置的網絡從

4G

切換到

WiFi

時，意味着IP位址變化了，那麼必須要斷開連接配接，然後重新連接配接，而建立連接配接的過程包含TCP三向交握和TLS四次揮手的時延，以及TCP慢啟動的減速過程，給使用者的感覺就是突然網絡卡頓了一下，是以說，遷移的成本是很高的。

http3是怎麼解決連接配接遷移

HTTP3

中

QUIC

協定沒有用四元組的方式來"綁定”連接配接，而是通過連接配接ID來标記通信的兩個端點，用戶端和伺服器可以各自選擇一組ID來标記自己，是以即使移動裝置的網絡變化後，導緻IP位址變化了，隻要仍保有上下文資訊(比如連接配接ID、TLS 密鑰等)，就可以"無縫"地複用原連接配接，消除重連的成本，沒有絲毫卡頓感，達到了連接配接遷移的功能。

11. TCP與UDP差別及場景

類型	特點	性能	應用過場景	首部位元組
TCP	面向連接配接、可靠、位元組流	傳輸效率慢、所需資源多	檔案、郵件傳輸	20-60
UDP	無連接配接、不可靠、資料封包段	傳輸效率快、所需資源少	語音、視訊、直播	8個位元組

基于TCP的協定：

HTTP

、

FTP

、

SMTP

基于UDP的協定：

RIP

、

DNS

、

SNMP

12. TCP滑動視窗，擁塞控制

TCP通過：應用資料分割、對資料包進行編号、校驗和、流量控制、擁塞控制、逾時重傳等措施保證資料的可靠傳輸。

擁塞控制目的：為了防止過多的資料注入到網絡中，避免網絡中的路由器、鍊路過載。

擁塞控制過程：TCP維護一個擁塞視窗，該視窗随着網絡擁塞程度動态變化，通過慢開始、擁塞避免等算法減少網絡擁塞的發生。

13. TCP粘包原因和解決方法

TCP粘包是指：發送方發送的若幹包資料到接收方接收時粘成一包

發送方原因：

TCP預設使用Nagle算法（主要作用：減少網絡中封包段的數量）：

收集多個小分組，在一個确認到來時一起發送、導緻發送方可能會出現粘包問題

接收方原因：

TCP将接收到的資料包儲存在接收緩存裡，如果TCP接收資料包到緩存的速度大于應用程式從緩存中讀取資料包的速度，多個包就會被緩存，應用程式就有可能讀取到多個首尾相接粘到一起的包。

傳輸層的UDP協定不會發生粘包或者拆包問題 UDP 是基于封包發送的，在 UDP 首部采用了16bit來訓示 UDP 資料封包的長度，是以在應用層能很好的将不同的資料封包區分開，進而避免粘包和拆包的問題。
傳輸層的TCP協定會發生粘包或者拆包問題

原因有以下兩點：
1. TCP 是基于位元組流的，雖然應用層和傳輸層之間的資料互動是大小不等的資料塊，但是 TCP 把這些資料塊僅僅看成一連串無結構的位元組流，沒有邊界；
2. 在 TCP 的首部沒有表示資料長度的字段，基于上面兩點，在使用 TCP 傳輸資料時，才有粘包或者拆包現象發生的可能。

解決粘包問題：解決問題的關鍵在于如何給每個資料包添加邊界資訊

最本質原因在與接收對等方無法分辨消息與消息之間的邊界在哪，通過使用某種方案給出邊界，例如：

發送定長包。每個消息的大小都是一樣的，接收方隻要累計接收資料，直到資料等于一個定長的數值就将它作為一個消息。
包尾加上\r\n标記。 FTP 協定正是這麼做的。但問題在于如果資料正文中也含有\r\n，則會誤判為消息的邊界。
標頭加上包體長度。標頭是定長的4個位元組，說明了包體的長度。接收對等方先接收包體長度，依據包體長度來接收包體。

14. TCP、UDP封包格式

TCP封包格式：

源端口号和目的端口号：

用于尋找發端和收端應用程序。這兩個值加上

IP

首部源端IP位址和目的端

IP

位址唯一确定一個

TCP

連接配接。

序号字段：

序号用來辨別從

TCP

發端向

TCP

收端發送的資料位元組流，它表示在這個封包段中的的第一個資料位元組。如果将位元組流看作在兩個應用程式間的單向流動，則

TCP

用序号對每個位元組進行計數。序号是32 bit的無符号數，序号到達 2^32-1後又從0開始。

當建立一個新的連接配接時，

SYN

标志變1。序号字段包含由這個主機選擇的該連接配接的初始序号ISN（Initial Sequence Number）。該主機要發送資料的第一個位元組序号為這個ISN加1，因為

SYN

标志消耗了一個序号

确認序号：

既然每個傳輸的位元組都被計數，确認序号包含發送确認的一端所期望收到的下一個序号。是以，确認序号應當是上次已成功收到資料位元組序号加 1。隻有

ACK

标志為 1時确認序号字段才有效。發送

ACK

無需任何代價，因為 32 bit的确認序号字段和A C K标志一樣，總是TCP首部的一部分。是以，我們看到一旦一個連接配接建立起來，這個字段總是被設定， ACK标志也總是被設定為1。TCP為應用層提供全雙工服務。這意味資料能在兩個方向上獨立地進行傳輸。是以，連接配接的每一端必須保持每個方向上的傳輸資料序号。

首都長度：

首部長度給出首部中 32 bit字的數目。需要這個值是因為任選字段的長度是可變的。這個字段占4 bit，是以TCP最多有6 0位元組的首部。然而，沒有任選字段，正常的長度是 20位元組。

标志字段：在

TCP

首部中有 6個标志比特，它們中的多個可同時被設定為1。

URG 緊急指針（u rgent pointer）有效
ACK 确認序号有效。
PSH 接收方應該盡快将這個封包段交給應用層。
RST 重建連接配接。
SYN 同步序号用來發起一個連接配接。這個标志和下一個标志将在第 1 8章介紹。
FIN 發端完成發送任務。

視窗大小：

TCP

的流量控制由連接配接的每一端通過聲明的視窗大小來提供。視窗大小為位元組數，起始于确認序号字段指明的值，這個值是接收端期望接收的位元組。視窗大小是一個 16 bit字段，因而視窗大小最大為 65535位元組。

檢驗和：

檢驗和覆寫了整個的

TCP

封包段：

TCP

首部和

TCP

資料。這是一個強制性的字段，一定是由發端計算和存儲，并由收端進行驗證。

緊急指針：

隻有當

URG

标志置1時緊急指針才有效。緊急指針是一個正的偏移量，和序号字段中的值相加表示緊急資料最後一個位元組的序号。

TCP

的緊急方式是發送端向另一端發送緊急資料的一種方式。

選項：

最常見的可選字段是最長封包大小，又稱為

MSS

(Maximum Segment Size)。每個連接配接方通常都在通信的第一個封包段（為建立連接配接而設定

SYN

标志的那個段）中指明這個選項。它指明本端所能接收的最大長度的封包段。

UDP封包格式：

端口号：

用來表示發送和接受程序。由于

IP

層已經把I P資料報配置設定給

TCP

或

UDP

（根據I P首部中協定字段值），是以

TCP

端口号由

TCP

來檢視，而

UDP

端口号由

UDP

來檢視。

TCP

端口号與

UDP

端口号是互相獨立的。

長度：

UDP

長度字段指的是

UDP

首部和

UDP

資料的位元組長度。該字段的最小值為 8位元組（發送一份0位元組的

UDP

資料報是 O K）。

檢驗和：

UDP

檢驗和是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是為了發現

UDP

首部和資料在發送端到接收端之間發生的任何改動。

IP封包格式：普通的IP首部長為20個位元組，除非含有可選項字段。

4位版本：目前協定版本号是4，是以IP有時也稱作IPV4.

4位首部長度：

首部長度指的是首部占

32bit

字的數目，包括任何選項。由于它是一個4比特字段，是以首部長度最長為60個位元組。

服務類型（TOS）：

服務類型字段包括一個

3bit

的優先權字段（現在已經被忽略），

4bit

的TOS子字段和1bit未用位必須置0。

4bit

的TOS分别代表：最小時延，最大吞吐量，最高可靠性和最小費用。4bit中隻能置其中1比特。如果所有4bit均為0，那麼就意味着是一般服務。

總長度：

總長度字段是指整個IP資料報的長度，以位元組為機關。利用首部長度和總長度字段，就可以知道IP資料報中資料内容的起始位置和長度。由于該字段長

16bit

，是以IP資料報最長可達65535位元組。當資料報被分片時，該字段的值也随着變化。

辨別字段：

辨別字段唯一地辨別主機發送的每一份資料報。通常每發送一份封包它的值就會加1。

生存時間：

TTL（time-to-live）生存時間字段設定了資料報可以經過的最多路由器數。它指定了資料報的生存時間。TTL的初始值由源主機設定（通常為 3 2或6 4），一旦經過一個處理它的路由器，它的值就減去 1。當該字段的值為 0時，資料報就被丢棄，并發送

ICMP

封包通知源主機。

首部檢驗和：

首部檢驗和字段是根據 I P首部計算的檢驗和碼。它不對首部後面的資料進行計算。

ICMP

、

IGMP

、

UDP

和

TCP

在它們各自的首部中均含有同時覆寫首部和資料檢驗和碼。

以太網封包格式：

目的位址和源位址：是指網卡的硬體位址（也叫MAC 位址），長度是48 位，是在網卡出廠時固化的。

資料：

以太網幀中的資料長度規定最小46 位元組，最大1500 位元組，

ARP

和

RARP

資料包的長度不夠46 位元組，要在後面補填充位。最大值1500 稱為以太網的最大傳輸單元（

MTU

），不同的網絡類型有不同的

MTU

，如果一個資料包從以太網路由到撥号鍊路上，資料包度大于撥号鍊路的

MTU

了，則需要對資料包進行分片fragmentation）。

ifconfig

指令的輸出中也有“MTU:1500”。注意，

MTU

個概念指資料幀中有效載荷的最大長度，不包括幀首部的長度。

15. TCP協定如何保證可靠傳輸機制？

TCP主要提供了檢驗和、序列号/确認應答、逾時重傳、滑動視窗、擁塞控制和流量控制等方法實作了可靠性傳輸。

檢驗和：通過檢驗和的方式，接收端可以檢測出來資料是否有差錯和異常，假如有差錯就會直接丢棄 TCP 段，重新發送。
序列号/确認應答：序列号的作用不僅僅是應答的作用，有了序列号能夠将接收到的資料根據序列号排序，并且去掉重複序列号的資料。 TCP 傳輸的過程中，每次接收方收到資料後，都會對傳輸方進行确認應答。也就是發送 ACK 封包,這個 ACK 封包當中帶有對應的确認序列号，告訴發送方，接收到了哪些資料，下一次的資料從哪裡發。
逾時重傳：逾時重傳是指發送出去的資料包到接收到确認包之間的時間，如果超過了這個時間會被認為是丢包了，需要重傳。最大逾時時間是動态計算的。
滑動視窗：滑動視窗既提高了封包傳輸的效率，也避免了發送方發送過多的資料而導緻接收方無法正常處理的異常。
擁塞控制：在資料傳輸過程中，可能由于網絡狀态的問題，造成網絡擁堵，此時引入擁塞控制機制，在保證 TCP 可靠性的同時，提高性能。
流量控制：如果主機A一直向主機B發送資料，不考慮主機B的接受能力，則可能導緻主機B的接受緩沖區滿了而無法再接受資料，進而會導緻大量的資料丢包，引發重傳機制。而在重傳的過程中，若主機B的接收緩沖區情況仍未好轉，則會将大量的時間浪費在重傳資料上，降低傳送資料的效率。是以引入流量控制機制，主機B通過告訴主機A自己接收緩沖區的大小，來使主機A控制發送的資料量。流量控制與 TCP 協定報頭中的視窗大小有關。

16. TCP的滑動視窗?

在進行資料傳輸時，如果傳輸的資料比較大，就需要拆分為多個資料包進行發送。

TCP

協定需要對資料進行确認後，才可以發送下一個資料包。這樣一來，就會在等待确認應答包環節浪費時間。為了避免這種情況，

TCP

引入了視窗概念。視窗大小指的是不需要等待确認應答包而可以繼續發送資料包的最大值。

從上面的圖可以看到滑動視窗左邊的是已發送并且被确認的分組，滑動視窗右邊是還沒有輪到的分組。

滑動視窗裡面也分為兩塊，一塊是已經發送但是未被确認的分組，另一塊是視窗内等待發送的分組。随着已發送的分組不斷被确認，視窗内等待發送的分組也會不斷被發送。整個視窗就會往右移動，讓還沒輪到的分組進入視窗内。

可以看到滑動視窗起到了一個限流的作用，也就是說目前滑動視窗的大小決定了目前

TCP

發送包的速率，而滑動視窗的大小取決于擁塞控制視窗和流量控制視窗的兩者間的最小值。

17. 詳細講一下擁塞控制? 為何要進行擁塞控制？

A在給B傳輸資料, A卻沒有收到B回報的

TCP

,A就認為B發送的資料包丢失了..進而會重新傳輸這個丢失的資料包。然而實際情況有可能此時有太多主機正在使用信道資源，導緻網絡擁塞了。重傳資料浪費了資源，是以要進行擁塞控制。發送發不知道一次發多少資料合适，是以設定一個擁塞視窗。

TCP擁塞控制原理是通過：慢啟動、擁塞避免、快重傳、快啟動

發送方維持一個叫做擁塞視窗cwnd (congestion window)的狀态變量。當cwndssthresh時，改用擁塞避免算法。

慢開始: 不要一開始就發送大量的資料，由小到大逐漸增加擁塞視窗的大小。
擁塞避免: 擁塞避免算法讓擁塞視窗緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1而不是加倍。這樣擁塞視窗按線性規律緩慢增長。
快重傳: 我們可以剔除一些不必要的擁塞封包，提高網絡吞吐量。比如接收方在收到一個失序的封包段後就立即發出重複确認，而不要等到自己發送資料時捎帶确認。快重傳規定:發送方隻要一連收到三個重複确認就應當立即重傳對方尚未收到的封包段，而不必繼續等待設定的重傳計時器時間到期。
快恢複: 主要是配合快重傳。當發送方連續收到三個重複确認時，就執行“乘法減小”算法，把ssthresh門限減半(為了預防網絡發生擁塞)，但接下來并不執行慢開始算法，因為如果網絡出現擁塞的話就不會收到好幾個重複的确認，收到三個重複确認說明網絡狀況還可以。

18. TCP擁塞控制4種算法

基于丢包的擁塞控制：将丢包視為出現擁塞，采取緩慢探測的方式，逐漸增大擁塞視窗，當出現丢包時，将擁塞視窗減小，如 Reno 、 Cubic 等。
基于時延的擁塞控制：将時延增加視為出現擁塞，延時增加時增大擁塞視窗，延時減小時減小擁塞視窗，如 Vegas 、 FastTCP 等。
基于鍊路容量的擁塞控制：實時測量網絡帶寬和時延，認為網絡上封包總量大于帶寬時延乘積時出現了擁塞，如 BBR 。
基于學習的擁塞控制：沒有特定的擁塞信号，而是借助評價函數，基于訓練資料，使用機器學習的方法形成一個控制政策，如 Remy 。

HTTP協定

1. HTTP協定1.0 1.1 2.0

HTTP1.0：伺服器處理完成後立即斷開

TCP

連接配接（無連接配接），伺服器不跟蹤每個用戶端也不記錄過去的請求（無狀态）

HTTP1.1：

KeepAlived

長連接配接避免了連接配接建立和釋放的開銷；通過

Content-Length

來判斷目前請求資料是否已經全部接受（有狀态）

HTTP2.0：引入二進制資料幀和流的概念，其中幀對資料進行順序辨別；因為有了序列，伺服器可以并行的傳輸資料。

無狀态的好壞

無狀态的好處，因為伺服器不會去記憶 HTTP 的狀态，是以不需要額外的資源來記錄狀态資訊，這能減輕伺服器的負擔，能夠把更多的 CPU 和記憶體用來對外提供服務。
無狀态的壞處，既然伺服器沒有記憶能力，這樣每操作一次，都要驗證資訊。例如登入->添加購物車->下單->結算->支付，這系列操作都要知道使用者的身份才行。但伺服器不知道這些請求是有關聯的，每次都要問一遍身份資訊。

解決無狀态的問題，解法方案有很多種，其中比較簡單的方式用

Cookie

和

Session

技術。

2. HTTP1.0和HTTP1.1的主要差別如下：

緩存處理：1.1添加更多的緩存控制政策（如： Entity tag ， If-Match ）
網絡連接配接的優化：1.1支援斷點續傳
錯誤狀态碼的增多：1.1新增了24個錯誤狀态響應碼，豐富的錯誤碼更加明确各個狀态
Host頭處理：支援 Host 頭域，不在以 IP 為請求方标志
長連接配接：減少了建立和關閉連接配接的消耗和延遲。

3. HTTP1.1和HTTP2.0的主要差別：

新的傳輸格式：2.0使用二進制格式，1.0依然使用基于文本格式
多路複用：連接配接共享，不同的 request 可以使用同一個連接配接傳輸（最後根據每個 request 上的id号組合成正常的請求）
header壓縮：由于1.X中 header 帶有大量的資訊，并且得重複傳輸，2.0使用 encoder 來減少需要傳輸的 hearder 大小
服務端推送：同 google 的 SPDUY （1.0的一種更新）一樣

4. HTTP和 HTTPS的差別：

最重要的差別就是安全性， HTTP 明文傳輸，不對資料進行加密安全性較差。 HTTPS (HTTP + SSL / TLS)的資料傳輸過程是加密的，安全性較好。
證書：使用 HTTPS 協定需要申請 CA 證書，一般免費證書較少，因而需要一定費用。證書頒發機構如： Symantec 、 Comodo 、 DigiCert 和 GlobalSign 等。
響應速度： HTTP 頁面響應速度比 HTTPS 快，這個很好了解，由于加了一層安全層，建立連接配接的過程更複雜，也要交換更多的資料，難免影響速度。
加密： HTTP 協定運作在 TCP （三次握手）之上，所有傳輸的内容都是明文， HTTPS 運作在 SSL/TLS 之上， SSL/TLS 運作在 TCP 之上，所有傳輸的内容都經過加密的。
端口不同： HTTPS 和 HTTP 使用的是完全不同的連接配接方式，用的端口也不一樣，前者是 443 ，後者是 80 。

HTTP	HTTPS
預設端口80	預設端口443
明文傳輸、資料未加密、安全性較差	傳輸協定ssl加密、安全性較好
響應速度快，消耗資源少	響應速度慢、消耗資源多，需要用到CA憑證

5. HTTPS 的缺點：

在相同網絡環境中， HTTPS 相比 HTTP 無論是響應時間還是耗電量都有大幅度上升。
HTTPS 的安全是有範圍的，在黑客攻擊、伺服器劫持等情況下幾乎起不到作用。
在現有的證書機制下，中間人攻擊依然有可能發生。
HTTPS 需要更多的伺服器資源，也會導緻成本的升高。

6. HTTPS連結建立的過程：

首先用戶端先給伺服器發送一個請求
伺服器發送一個 SSL 證書給用戶端，内容包括：證書的釋出機構、有效期、所有者、簽名以及公鑰
用戶端對發來的公鑰進行真僞校驗，校驗為真則使用公鑰對對稱加密算法以及對稱密鑰進行加密
伺服器端使用私鑰進行解密并使用對稱密鑰加密确認資訊發送給用戶端
随後用戶端和服務端就使用對稱密鑰進行資訊傳輸

加密流程按圖中的序号分為:

用戶端請求 HTTPS 網址，然後連接配接到 server 的443端口( HTTPS 預設端口，類似于 HTTP 的80端口)。
采用 HTTPS 協定的伺服器必須要有一套數字 CA (Certification Authority)證書。頒發證書的同時會産生一個私鑰和公鑰。私鑰由服務端自己儲存，不可洩漏。公鑰則是附帶在證書的資訊中，可以公開的。證書本身也附帶-一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被篡改。
伺服器響應用戶端請求，将證書傳遞給用戶端，證書包含公鑰和大量其他資訊，比如證書頒發機構資訊，公司資訊和證書有效期等。
用戶端解析證書并對其進行驗證。如果證書不是可信機構頒布，或者證書中的域名與實際域名不一緻，或者證書已經過期，就會向通路者顯示一個警告，由其選擇是否還要繼續通信。如果證書沒有問題，用戶端就會從伺服器證書中取出伺服器的公鑰A。然後用戶端還會生成一一個随機碼 KEY ,并使用公鑰A将其加密。
用戶端把加密後的随機碼 KEY 發送給伺服器，作為後面對稱加密的密鑰。
伺服器在收到随機碼 KEY 之後會使用私鑰B将其解密。經過以上這些步驟，用戶端和伺服器終于建立了安全連接配接，完美解決了對稱加密的密鑰洩露問題，接下來就可以用對稱加密愉快地進行通信了。
伺服器使用密鑰(随機碼 KEY )對資料進行對稱加密并發送給用戶端，用戶端使用相同的密鑰(随機碼 KEY )解密資料。
雙方使用對稱加密愉快地傳輸所有資料。

7. HTTP常見響應狀态碼

：Continue 一一繼續。用戶端應繼續其請求。

：OK 一一請求成功。一般用于GET與POST請求。

：Moved Permanently 一一永久重定向。

：Found 一一暫時重定向。

：Bad Request 一一用戶端請求的文法錯誤，伺服器無法了解。請求沒有包含host頭

：Forbideen 一一伺服器了解請求用戶端的請求，但是拒絕執行此請求。禁止客戶通路該資源

：Not Found 一一伺服器無法根據用戶端的請求找到資源（網頁）。資源未找到

：Internal Server Error 一一伺服器内部錯誤，無法完成請求。

：Bad Gateway 一一作為網關或者代理伺服器嘗試執行請求時，從遠端伺服器接收到了無效的響應。

8. 狀态碼301和302的差別是什麼?

為永久重定向，

為臨時重定向

共同點:

和

狀态碼都表示重定向，就是說浏覽器在拿到伺服器傳回的這個狀态碼後會自動跳轉到一個新的URL位址，這個位址可以從響應的Location首部中擷取(使用者看到的效果就是他輸入的位址A瞬間變成了另一個位址B)。

不同點:

表示舊位址A的資源已經被永久地移除了(這個資源不可通路了)，搜尋引擎在抓取新内容的同時也将舊的網址交換為重定向之後的網址;

表示舊位址A的資源還在(仍然可以通路)，這個重定向隻是臨時地從舊位址A跳轉到位址B，搜尋引擎會抓取新的内容而儲存舊的網址。SEO中

好于

。

補充，重定向原因:

網站調整(如改變網頁目錄結構);
網頁被移到一個新位址;
網頁擴充名改變(如應用需要把.php改成.Html或.shtml)。

9. 對稱加密算法與非對稱加密算法的差別

對稱加密算法：

雙方持有相同的密鑰，且加密速度快，典型對稱加密算法：

DES

、

AES

非對稱加密算法：

密鑰成對出現（私鑰、公鑰），私鑰隻有自己知道，不在網絡中傳輸；而公鑰可以公開。相比對稱加密速度較慢，典型的非對稱加密算法有：

AES

、

DSA

10. HTTP請求方法：

方法	描述
GET	像特定資源發送請求，查詢資料，并傳回實體
POST	向指定資源送出資料進行處理，可能會導緻新的資源建立、已有的資源修改
PUT	向伺服器上傳新的内容
HEAD	類似GET請求，傳回的響應式中沒有具體内容，用于擷取報頭
DELETE	請求伺服器删除指定辨別的資源
OPTIONS	可以原來向伺服器發送請求來測試伺服器的功能性
TRACE	回顯伺服器收到的請求，用于測試和診斷
CONNECT	HTTP/1.1協定中預留給能夠将連接配接改為管道方式的代理伺服器

11. Get和Post請求差別

GET	POST
HTTP規範	GET用于資訊擷取	修改伺服器上的資源的請求
可見性	資料在URL中對所有人可見	資料不會顯示在URL中
安全性	與post相比，get的安全性較差，因為所發送的資料是URL的一部分	安全，因為參數不會被儲存在浏覽器曆史或web伺服器日志中
資料長度	受限制，最長2kb	無限制
編碼類型	application/x-www-form-urlencoded	multipart/form-data
緩存	能被緩存	不能被緩存

12. GET 和 POST 方法都是安全和幂等的嗎？

先說明下安全和幂等的概念：

在 DSA 協定裡，所謂的「安全」是指請求方法不會「破壞」伺服器上的資源。
所謂的「幂等」，意思是多次執行相同的操作，結果都是「相同」的。

那麼很明顯 GET 方法就是安全且幂等的，因為它是「隻讀」操作，無論操作多少次，伺服器上的資料都是安全的，且每次的結果都是相同的。

POST

因為是「新增或送出資料」的操作，會修改伺服器上的資源，是以是不安全的，且多次送出資料就會建立多個資源，是以不是幂等的。

13. 重定向和轉發差別

轉發是伺服器行為,重定向是用戶端行為

重定向：redirect：

位址欄發生變化

重定向可以通路其他站點（伺服器）的資源

重定向是兩次請求。不能使用request對象來共享資料

轉發：forward：

轉發位址欄路徑不變

轉發隻能通路目前伺服器下的資源

轉發是一次請求，可以使用

request

對象共享資料

14. Cookie和Session差別

Cookie 和 Session都是用來跟蹤浏覽器使用者身份的會話方式，但兩者有所差別：

Cookie

資料儲存在用戶端(浏覽器端)，

Session

資料儲存在伺服器端。

cookie

不是很安全，别人可以分析存放在本地的

Cookie

并進行欺騙,考慮到安全應當使用session。

Cookie

⼀般⽤來儲存⽤戶資訊，

Session

的主要作⽤就是通過服務端記錄⽤戶的狀态

15. 浏覽器輸入URL過程

過程：

DNS

解析、

TCP

連接配接、發送

HTTP

請求、伺服器處理請求并傳回

HTTP

封包、浏覽器渲染、結束

域名解析(域名www.baidu.com變為IP位址)。浏覽器搜尋自己的 DNS 緩存(維護一張域名與IP的對應表);
1. 若沒有，則搜尋作業系統的 DNS 緩存(維護一張域名與IP的對應表) ;
2. 若沒有，則搜尋作業系統的hosts檔案(維護一張域名與IP的對應表)。
3. 若都沒有，則找TCP/IP參數中設定的首選dns伺服器，即本地 DNS 伺服器(遞歸查詢)，本地域名伺服器查詢自己的 DNS 緩存，如果沒有，則進行疊代查詢。将本地dns伺服器将IP傳回給作業系統，同時緩存IP。
發起 TCP 的三次握手，建立 TCP 連接配接。浏覽器會以一個随機端口(1024-65535) 向服務端的web程式80端口發起 TCP 的連接配接。
建立 TCP 連接配接後發起HTTP請求。
伺服器響應 HTTP 請求，用戶端得到 html 代碼。伺服器web應用程式收到 HTTP 請求後，就開始處理請求，處理之後就傳回給浏覽器 html 檔案。
浏覽器解析 html 代碼，并請求 html 中的資源。
浏覽器對頁面進行渲染，并呈現給使用者。

如何檢視 TCP 的連接配接狀态？TCP 的連接配接狀态檢視，在 Linux 可以通過 netstat -napt 指令檢視。

16. DNS協定是TCP還是UDP?

DNS 占用53号端口，同時使用 TCP 和 UDP 協定。那麼 DNS
在什麼情況下使用這兩種協定？

DNS在區域傳輸的時候使用TCP協定，其他時候使用UDP協定。
- 用戶端向 DNS 伺服器查詢域名，一般傳回的内容都不超過512位元組，用 UDP 傳輸即可。不用經過 TCP 三次握手，這樣 DNS 伺服器負載更低，響應更快。雖然從理論上說，用戶端也可以指定向 DNS 伺服器查詢的時候使用 TCP ，但事實上，很多 DNS 伺服器進行配置的時候，僅支援 UDP 查詢包。
- 輔域名伺服器會定時（一般3小時）向主域名伺服器進行查詢以便了解資料是否有變動。如有變動，會執行一次區域傳送，進行資料同步。區域傳送使用 TCP 而不是 UDP ，因為資料同步傳送的資料量比一個請求應答的資料量要多得多。
- TCP 是一種可靠連接配接，保證了資料的準确性。
- DNS區域傳輸的時候使用TCP協定：
- 域名解析時使用UDP協定：

17. ARP協定如何找到對應IP位址和mac的映射的

簡單地說，

ARP

是借助

ARP

請求與

ARP

響應兩種類型的包确定

MAC

位址的。

主機會通過廣播發送 ARP 請求，這個包中包含了想要知道的 MAC 位址的主機 IP 位址。
當同個鍊路中的所有裝置收到 ARP 請求時，會去拆開 ARP 請求包裡的内容，如果 ARP 請求包中的目标 IP 位址與自己的 IP 位址一緻，那麼這個裝置就将自己的 MAC 位址塞入 ARP 響應包傳回給主機。

作業系統通常會把第一次通過

ARP

擷取的

MAC

位址緩存起來，以便下次直接從緩存中找到對應 IP 地址的

MAC

位址。不過，

MAC

位址的緩存是有一定期限的，超過這個期限，緩存的内容将被清除

18. RARP 協定你知道是什麼嗎？

ARP 協定是已知 IP 位址求

MAC

位址，那

RARP

協定正好相反，它是已知

MAC

位址求 IP 位址。例如将列印機伺服器等小型嵌入式裝置接入到網絡時就經常會用得到。

通常這需要架設一台

RARP

伺服器，在這個伺服器上注冊裝置的

MAC

位址及其 IP 位址。然後再将這個裝置接入到網絡，接着：

該裝置會發送一條「我的 MAC 位址是XXXX，請告訴我，我的IP位址應該是什麼」的請求資訊。
RARP 伺服器接到這個消息後傳回「 MAC 位址為 XXXX 的裝置，IP位址為 XXXX」的資訊給這個裝置。

最後，裝置就根據從

RARP

伺服器所收到的應答資訊設定自己的 IP 位址

19. 什麼是DDos攻擊?

DDos

全稱Distributed Denial of Service，分布式拒絕服務攻擊。最基本的DOS攻擊過程如下:

用戶端向服務端發送請求連結資料包。
服務端向用戶端發送确認資料包。
用戶端不向服務端發送确認資料包，伺服器一直等待來自用戶端的确認

DDos

則是采用分布式的方法，通過在網絡上占領多台“殭屍電腦”，用多台計算機發起攻擊。

DDos

攻擊現在基本沒啥作用了，因為伺服器的性能都很好，而且是多台伺服器共同作用，1V1的模式黑客無法占上風。對于

DDos

攻擊，預防方法有:

減少SYN timeout時間。在握手的第三步，伺服器會等待30秒-120秒的時間，減少這個等待時間就能釋放更多的資源。
限制同時打開的SYN半連接配接數目。

20. 什麼是XSS攻擊?

XSS也稱cross-sitescripting,跨站腳本。這種攻擊是由于伺服器将攻擊者存儲的資料原原本本地顯示給其他使用者所緻的。比如一個存在XSS漏洞的論壇，使用者發帖時就可以引入帶有< script>标簽的代碼，導緻惡意代碼的執行。

預防措施有:

前端：過濾。
後端：轉義，比如go自帶的處理器就具有轉義功能。

21. SQL注入是什麼，如何避免SQL注入?

SQL

注入就是在使用者輸入的字元串中加入

SQL

語句，如果在設計不良的程式中忽略了檢查，那麼這些注入進去的

SQL

語句就會被資料庫伺服器誤認為是正常的

SQL

語句而運作，攻擊者就可以執行計劃外的指令或通路未被授權的資料。

SQL

注入的原理主要有以下4點：

惡意拼接查詢
利用注釋執行非法指令
傳入非法參數
添加額外條件

避免

SQL

注入的一些方法：

參數校驗：在一些不該有特殊字元的參數中提前進行特殊字元校驗即可。
限制資料庫權限，給使用者提供僅僅能夠滿足其工作的最低權限。
提供參數化查詢接口，不要直接使用原生 SQL 。
SQL預編譯

在知道了

SQL

注入的原理之後，我們同樣也了解到

MySQL

有預編譯的功能，指的是在伺服器啟動時，

MySQL

Client把

SQL

語句的模闆（變量采用占位符進行占位）發送給

MySQL

伺服器，

MySQL

伺服器對

SQL

語句的模闆進行編譯，編譯之後根據語句的優化分析對相應的索引進行優化，在最終綁定參數時把相應的參數傳送給

MySQL

伺服器，直接進行執行，節省了

SQL

查詢時間，以及

MySQL

伺服器的資源，達到一次編譯、多次執行的目的，除此之外，還可以防止SQL注入。

具體是怎樣防止

SQL

注入的呢？實際上當将綁定的參數傳到

MySQL