一、介紹TCP 連接的三次握手？追問：爲什麼 TCP 握手需要三次？

TCP是面向連接的可靠傳輸協議

面向連接：三次握手

可靠傳輸：確認、重傳、排序、流控（滑動窗口）

傳輸層的協議

其協議頭部有20個字節分爲五個四字節

第一行四字節是源目端口各佔兩字節 16bit

第二行是序列號佔四字節 32bit

第三行是確認序列號佔四字節 32bit

第四行是 4bit的頭部長度 6位保留 6位標誌位 16位窗口大小

第五行是16位校驗和 16位緊急指針

TCP會話建立圖解如下，可以很明顯的看出來，客戶端的SYN請求需要服務器的ACK確認，而服務器的SYN請求需要客戶端的確認，所以握手需要三次

ACK ： TCP協議規定，只有ACK=1時有效，也規定連接建立後所有發送的報文的ACK必須爲1

SYN(SYNchronization) ：在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。

二、介紹 TCP 斷開的四次揮手，追問：爲什麼 TCP 的揮手需要四次？

四次揮手的圖解如下，可以明顯的看出來，客戶端的FIN（請求釋放連接）需要服務器的ACK確認，而服務器的FIN需要客戶端的ACK

三、TCP 的 syn 攻擊的過程？追問：怎麼防禦？

過程

攻擊者僞造不存在的主機IP 向服務器發送大量的SYN包，使服務器的緩存造成溢出，即不能處理正常的SYN請求，這屬於DDOS攻擊

防禦

具有SYN proxy（SYN代理）功能的防火牆
加快淘汰無效SYN請求
SYN Cookie

四、爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？

連接時，每次的SYN請求需要ACK確認，所以是三次

關閉時，需要客戶端與服務器端的都發送FIN並且進行確認，所以是四次

五、TCP 是如何通過滑動窗口協議實現流量控制和擁塞控制的？

流量控制

擁塞控制

六、描述 TCP 和 UDP 的區別？

不同點：

協議層面：

TCP是面向連接的可靠傳輸協議協議號爲6

UDP是非面向連接的不可靠傳輸協議號爲17

傳輸層面：

TCP只能一對一傳輸且需要維護連接狀態通過流模式傳輸數據

UDP支持一對一、一對多、多對一、多對多且不需要建立連接通過數據報模式傳輸數據

說明：

流模式是指存在緩存區，傳進來的數據先進入緩衝區；防止發送方發送的數據太大導致接收方接受不了，而數據報追求的是速度，即即時性的將發送方發送的數據發送至接收方

數據層面：

TCP保證數據正確性、不丟包、不重複、有順序

UDP只盡最大努力交付、不保證可靠性

適用場景

TCP適合網絡負擔不大，可靠性要求高的場景

UDP適合網絡負擔大、響應高、客戶端較多、可靠性要求不高的場景

報文層面：

封裝的報文頭大小不同 TCP 20byte UDP 8byte

七、TCP 有哪些定時器？

建立連接定時器(connection-establishment timer)
重傳定時器(retransmission timer)
延遲應答定時器(delayed ACK timer)
堅持定時器(persist timer)
保活定時器(keepalive timer)
FIN_WAIT_2定時器(FIN_WAIT_2 timer)
TIME_WAIT定時器 (TIME_WAIT timer, 也叫2MSL timer)

建立連接定時器(connection-establishment timer)

顧名思義，這個定時器是在建立連接的時候使用的，我們知道， TCP建立連接需要3次握手，如下圖所示：

建立連接的過程中，在發送SYN時，會啓動一個定時器(默認應該是3秒)，如果SYN包丟失了，那麼3秒以後會重新發送SYN包的(當然還會啓動一個新的定時器，設置成6秒超時)，當然也不會一直沒完沒了的發SYN包，在/proc/sys/net/ipv4/tcp_syn_retries 可以設置到底要重新發送幾次SYN包。

重傳定時器(retransmission timer)

重傳定時器在TCP發送數據時設定，在計時器超時後沒有收到返回的確認ACK，發送端就會重新發送隊列中需要重傳的報文段。使用RTO重傳計時器一般有如下規則：

當TCP發送了位於發送隊列最前端的報文段後就啓動這個RTO計時器；
如果隊列爲空則停止計時器，否則重啓計時器；
當計時器超時後，TCP會重傳發送隊列最前端的報文段；
當一個或者多個報文段被累計確認後，這個或者這些報文段會被清除出隊列

重傳計時器保證了接收端能夠接收到丟失的報文段，繼而保證了接收端交付給接收進程的數據始終的有序完整的。因爲接收端永遠不會把一個失序不完整的報文段交付給接收進程。

延遲應答定時器(delayed ACK timer)

延遲應答也被稱爲捎帶ACK，這個定時器是在延遲應答的時候使用的。爲什麼要延遲應答呢？延遲應答是爲了提高網絡傳輸的效率。

舉例說明，比如服務端收到客戶端的數據後，不是立刻回ACK給客戶端，而是等一段時間(一般最大200ms)，這樣如果服務端要是有數據需要發給客戶端，那麼這個ACK就和服務端的數據一起發給客戶端了，這樣比立即回給客戶端一個ACK節省了一個數據包。

堅持定時器(persist timer)

我們已經知道TCP通過讓接收方指明希望從發送方接收的數據字節數（即窗口大小）來進行流量控制。如果窗口大小爲 0會發生什麼情況呢？這將有效地阻止發送方傳送數據，直到窗口變爲非0爲止。接收端窗口變爲非0後，就會發送一個確認ACK指明需要的報文段序號以及窗口大小。

如果這個確認ACK丟失了，則雙方就有可能因爲等待對方而使連接終止：接收方等待接收數據（因爲它已經向發送方通告了一個非0的窗口），而發送方在等待允許它繼續發送數據的窗口更新。爲防止這種死鎖情況的發生，發送方使用一個堅持定時器 (persist timer)來週期性地向接收方查詢，以便發現窗口是否已增大。這些從發送方發出的報文段稱爲窗口探查 (window probe)。

保活定時器(keepalive timer)

在TCP連接建立的時候指定了SO_KEEPALIVE，保活定時器纔會生效。如果客戶端和服務端長時間沒有數據交互，那麼需要保活定時器來判斷是否對端還活着，但是這個其實很不實用，因爲默認是2小時沒有數據交互才探測，時間實在是太長了。如果你真的要確認對端是否活着，那麼應該自己實現心跳包，而不是依賴於這個保活定時器。

FIN_WAIT_2定時器(FIN_WAIT_2 timer)

主動關閉的一端調用完close以後（即發FIN給被動關閉的一端，並且收到其對FIN的確認ACK）則進入FIN_WAIT_2狀態。如果這個時候因爲網絡突然斷掉、被動關閉的一段宕機等原因，導致主動關閉的一端不能收到被動關閉的一端發來的FIN，主動關閉的一段總不能一直傻等着，佔着資源不撒手吧？這個時候就需要FIN_WAIT_2定時器出馬了，如果在該定時器超時的時候，還是沒收到被動關閉一端發來的FIN，那麼不好意思，不等了，直接釋放這個鏈接。FIN_WAIT_2定時器的時間可以從/proc/sys/net/ipv4/tcp_fin_timeout中查看和設置。

TIME_WAIT定時器 (TIME_WAIT timer, 也叫2MSL timer)

TIME_WAIT是主動關閉連接的一端最後進入的狀態，而不是直接變成CLOSED的狀態，爲什麼呢？第一個原因是萬一被動關閉的一端在超時時間內沒有收到最後一個ACK，則會重發最後的FIN，2MSL（報文段最大生存時間）等待時間保證了重發的FIN會被主動關閉的一段收到且重新發送最後一個ACK；另外一個原因是在2MSL等待時間時，任何遲到的報文段會被接收並丟棄，防止老的TCP連接的包在新的TCP連接裏面出現。不可避免的，在這個2MSL等待時間內，不會建立同樣(源IP, 源端口，目的IP，目的端口)的連接。

八、什麼是 CDN？CDN 是如何工作的？

CDN

CDN是Content Delivery Network的簡稱，即“內容分發網絡”的意思。一般我們所說的CDN加速，一般是指網站加速或者用戶下載資源加速。

詳細解釋：

舉個通俗的例子：

　　談到CDN的作用，可以用8年買火車票的經歷來形象比喻：8年前，還沒有火車票代售點一說， 12306.cn更是無從說起。那時候火車票還只能在火車站的售票大廳購買，而小縣城並不通火車，火車票都要去市裏的火車站購買，而從縣城到市裏，來回就是4個小時車程，簡直就是浪費生命。

　　後來就好了，小縣城裏出現了火車票代售點，可以直接在代售點購買火車，方便了不少，全市人民再也不用在一個點苦逼的排隊買票了。

　　CDN就可以理解爲分佈在每個縣城的火車票代售點，用戶在瀏覽網站的時候， CDN會選擇一個離用戶最近的CDN邊緣節點來響應用戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務器(假設源站部署在北京電信機房)上了。

CDN的優勢很明顯：

(1)CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低;

(2)大部分請求在CDN邊緣節點完成， CDN起到了分流作用，減輕了源站的負載。

CDN緩存是什麼?

　　首先，看看沒有網站沒有接入CDN時，用戶瀏覽器與服務器是如何交互的：

　　用戶在瀏覽網站的時候，瀏覽器能夠在本地保存網站中的圖片或者其他文件的副本，這樣用戶再次訪問該網站的時候，瀏覽器就不用再下載全部的文件，減少了下載量意味着提高了頁面加載的速度。

　　如果中間加上一層CDN，那麼用戶瀏覽器與服務器的交互如下：

　　客戶端瀏覽器先檢查是否有本地緩存是否過期，如果過期，則向CDN邊緣節點發起請求， CDN邊緣節點會檢測用戶請求數據的緩存是否過期，如果沒有過期，則直接響應用戶請求，此時一個完成http請求結束;如果數據已經過期，那麼CDN還需要向源站發出回源請求(back to the source request),來拉取最新的數據。 CDN的典型拓撲圖如下：