三次握手和四次揮手

三次握手
??所謂的三次握手即TCP連接的建立，這個連接必須是一方主動打開，另一方被動打開的，以下為客戶端主動發起連接的圖解：

??握手之前主動打開連接的客戶端結束CLOSED階段，被動打開的服務器端也結束CLOSED階段，并進入LISTEN階段，隨后開始“三次握手”：

• 第一次握手：首先客戶端向服務器端發送一段TCP報文，其中：
  標記位為SYN，表示“請求建立新連接”;
  序號為Seq=X；初始化序號ISN是動態隨機的；
  隨后客戶端進入SYN-SENT階段，
• 第二次握手：服務器端接收到來自客戶端的TCP報文之后，結束LISTEN階段，并回傳一段TCP報文，其中：
  標志位為SYN和ACK，表示“確認客戶端的報文Seq序號有效，服務器能正常接收客戶端發送的資料，并同意創建新連接”（即告訴客戶端，服務器收到了你的資料）；
  序號為Seq=y；
  確認號為Ack=x+1，表示收到客戶端的序號Seq并將其值加1作為自己確認號Ack的值；隨后服務器端進入SYN-RCVD階段，
• 第三次握手：客戶端接收到來自服務器端的確認收到資料的TCP報文之后，明確了從客戶端到服務器的資料傳輸是正常的，結束SYN-SENT階段，并回傳最后一段TCP報文，其中：
  標志位為ACK，表示“確認收到服務器端同意連接的信號”（即告訴服務器，我知道你收到我發的資料了）；
  序號為Seq=x+1，表示收到服務器端的確認號Ack，并將其值作為自己的序號值；
  確認號為Ack=y+1，表示收到服務器端序號Seq，并將其值加1作為自己的確認號Ack的值；
  隨后客戶端進入ESTABLISHED階段，
  服務器收到來自客戶端的“確認收到服務器資料”的TCP報文之后，明確了從服務器到客戶端的資料傳輸是正常的，結束SYN-SENT階段，進入ESTABLISHED階段，

??在客戶端與服務器端傳輸的TCP報文中，雙方的確認號Ack和序號Seq的值，都是在彼此Ack和Seq值的基礎上進行計算的，這樣做保證了TCP報文傳輸的連貫性，一旦出現某一方發出的TCP報文丟失，便無法繼續"握手"，以此確保了"三次握手"的順利完成，

Q：為什么進行三次握手？
??為了防止服務器端開啟一些無用的連接增加服務器開銷以及防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤，

??由于網路傳輸是有延時的(要通過網路光纖和各種中間代理服務器)，在傳輸的程序中，比如客戶端發起了SYN=1創建連接的請求(第一次握手)，如果服務器端就直接創建了這個連接并回傳包含SYN、ACK和Seq等內容的資料包給客戶端，這個資料包因為網路傳輸的原因丟失了，丟失之后客戶端就一直沒有接收到服務器回傳的資料包，

??客戶端可能設定了一個超時時間，時間到了就關閉了連接創建的請求，再重新發出創建連接的請求，而服務器端是不知道的，如果沒有第三次握手告訴服務器端客戶端收的到服務器端傳輸的資料的話，服務器端是不知道客戶端有沒有接收到服務器端回傳的資訊的，這個程序可理解為：

??這樣沒有給服務器端一個創建還是關閉連接埠的請求，服務器端的埠就一直開著，等到客戶端因超時重新發出請求時，服務器就會重新開啟一個埠連接，那么服務器端上沒有接收到請求資料的上一個埠就一直開著，長此以往，這樣的埠多了，就會造成服務器端開銷的嚴重浪費，

??還有一種情況是已經失效的客戶端發出的請求資訊，由于某種原因傳輸到了服務器端，服務器端以為是客戶端發出的有效請求，接收后產生錯誤，

??所以我們需要“第三次握手”來確認這個程序，讓客戶端和服務器端能夠及時地察覺到因為網路等一些問題導致的連接創建失敗，這樣服務器端的埠就可以關閉了不用一直等待，即可以減少服務器開銷和接收到失效請求發生的錯誤，

四次揮手
那TCP 的四次揮手，是為了保證通信雙方都關閉了連接，具體程序如下：

1）客戶端 A 發送一個 FIN，用來關閉客戶 A 到服務器 B 的資料傳送；
2）服務器 B 收到這個 FIN，它發回一個 ACK，確認序號為收到的序號加 1，和 SYN 一樣，一個 FIN 將占用一個序號；
3）服務器 B 關閉與客戶端 A 的連接，發送一個 FIN 給客戶端 A；
4）客戶端 A 發回 ACK 報文確認，并將確認序號設定為收到序號加 1，

Q：為什么建立連接協議是三次握手，而關閉連接卻是四次握手呢？

??這是因為服務端的 LISTEN 狀態下的 SOCKET 當收到 SYN 報文的建連請求后，它可以把 ACK 和 SYN（ACK 起應答作用，而 SYN 起同步作用）放在一個報文里來發送，但關閉連接時，當收到對方的 FIN 報文通知時，它僅僅表示對方沒有資料發送給你了，但是你還可以給對方發送資料，或者還有一些資料在傳給對方的途中，所以你不能立馬關閉連接，也即你可能還需要把在傳輸途中的資料給對方之后，又或者，你還有一些資料需要傳輸給對方后，（再關閉連接）再發送FIN 報文給對方來表示你同意現在可以關閉連接了，所以它這里的 ACK 報文和 FIN 報文多數情況下都是分開發送的，

Q：為什么客戶端在TIME_WAIT 狀態還需要等 2MSL后才能回傳到 CLOSED 狀態？

??為的是確認服務器端是否收到客戶端發出的ACK確認報文；當客戶端發出最后的ACK確認報文時，并不能確定服務器端能夠收到該段報文，所以客戶端在發送完ACK確認報文之后，會設定一個時長為2MSL的計時器，MSL指的是Maximum Segment Lifetime：一段TCP報文在傳輸程序中的最大生命周期，2MSL即是服務器端發出為FIN報文和客戶端發出的ACK確認報文所能保持有效的最大時長（一個來回的時間），服務器端在1MSL內沒有收到客戶端發出的ACK確認報文，就會再次向客戶端發出FIN報文；

初始化序列號 ISN(s)
ISN代表什么？意義何在？

??ISN，發送方的位元組資料編號的原點，讓對方生成一個合法的接收視窗，

ISN是固定不變的嗎？

??動態隨機，

ISN為何要動態隨機？

??增加安全性，為了避免被第三方猜測到，從而被第三方偽造的RST報文Reset，

剛才你提到第三方可以偽造RST報文，需要滿足什么條件才能得逞？
??需要sequence number 位于對方的合法接收視窗內， 而由于ISN是動態隨機的，猜出對方合法接收視窗難度加大，如果ISN = 0，那就很容易猜出來了；

三次握手的第一次可以攜帶資料嗎？為何？
??不可以，三次握手還沒有完成；

對方難道不可以將資料快取下來，等握手成功再提交給應用程式？
??這樣會放大SYN FLOOD攻擊，如果攻擊者偽造了成千上萬的握手報文，攜帶了1K+ 位元組的資料，而接收方會開辟大量的快取來容納這些巨大資料，記憶體會很容易耗盡，從而拒絕服務，

第三次可以攜帶資料嗎？為何？

??可以；第三次本就是向服務器回復已收到服務器的請求連接資訊，自然可以攜帶資訊；服務器會在三次握手完成后，處理你發送的資料；

能夠發出第三次握手報文的主機，肯定接收到第二次(服務器)握手報文，對嗎？

??因為偽造IP的主機是不會接收到第二次報文的，所以，能夠發出第三次握手報文的，應該是合法的用戶，盡管服務器側的狀態還沒有“established”，接收到第三次握手的瞬間，狀態就會切換為“established”，里面攜帶的資料按照正常流程走就好，

看到有人說，只看到過TCP狀態位為 ’FIN +ACK’，但從來沒有看過狀態位只有 ‘FIN’，你應該怎樣給他解釋？
??RFC793明確規定，除了第一個握手報文SYN除外，其它所有報文必須將ACK = 1，

RFC規定的背后肯定有合理性的一面，能否深究一下原因？
??TCP作為一個可靠傳輸協議，其可靠性就是依賴于收到對方的資料，ACK對方，這樣對方就可以釋放快取的資料（因為一但訊息丟失，就要進行重發，重發緩沖區里面的資料），因為對方確信資料已經被接收到了，但TCP報文是在IP網路上傳輸，丟包是家常便飯，接收方要抓住一切的機會，把訊息告訴發送方，最方便的方式就是，任何我方發送的TCP報文，都要捎帶著ACK狀態位，

ACK狀態位單獨能承擔這個訊息傳遞的任務嗎？
??不能！需要有 Acknowledge Number配合才行，如果我方發出的Acknowledge Number == 10001，那意味著序列號10000及之前的位元組已經成功接收，如果對方占據位元組序列號10000是應用層資料，那么就是確認應用層資料，如果對方占據位元組序列號10000是’FIN’狀態位，那么就是確認接收到對方的’FIN’，

Q：為什么要三次握手？
??三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是資料的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的；

Q：兩次握手不行嗎？為什么TCP客戶端最后還要發送一次確認呢？

??主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤，經典場景：客戶端發送了第一個請求連接并且沒有丟失，只是因為在網路結點中滯留的時間太長了；

??由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸資料，然后關閉連接，此時此前滯留的那一次請求連接，網路通暢了到達服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費，如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文并且回復了確認報文，但是客戶端不會再次發出確認，由于服務器收不到確認，就知道客戶端并沒有請求連接，

Q：為什么三次握手，回傳時，ack 值是 seq 加 1（ack = x+1）

??假設對方接收到資料，比如sequence number = 1000，TCP Payload = 1000，資料第一個位元組編號為1000，最后一個為1999，回應一個確認報文，確認號為2000，意味著編號2000前的位元組接收完成，準備接收編號為2000及更多的資料；確認收到的序列，并且告訴發送端下一次發送的序列號從哪里開始（便于接收方對資料排序，便于選擇重傳）

Q：SYN洪泛攻擊(SYN Flood，半開放攻擊)，怎么解決？

什么是SYN洪范泛攻擊？
??SYN Flood洪泛攻擊發生在osl第四層，這種方式利用TCP協議的特性，就是三次握手，攻擊者發送TCP SYN，SYN是TCP三次握手中的第一個資料包，而當服務器回傳ACK后，該攻擊者就不對其進行再確認，那這個TCP連接就處于掛起狀態，也就是所謂的半連接狀態，服務器收不到再確認的話，還會重復發送ACK給攻擊者，這樣更加會浪費服務器的資源，攻擊者就對服務器發送非常大量的這種TCP連接，由于每一個都沒法完成三次握手，所以在服務器上，這些TCP連接會因為掛起狀態而消耗cPU和記憶體，最后服務器可能死機，就無法為正常用戶提供服務了；

??檢測 SYN 攻擊非常的方便，當你在服務器上看到大量的半連接狀態時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊【在 Linux/Unix 上可以使用系統自帶的 netstats 命令來檢測 SYN 攻擊】

怎么解決？

• 縮短超時（SYN Timeout）時間
• 增加最大半連接數
• 過濾網關防護

SYN cookies技術：
??當服務器接受到 SYN 報文段時，不直接為該 TCP 分配資源，而只是打開一個半開的套接字，接著會使用 SYN 報文段的源 Id，目的 Id，埠號以及只有服務器自己知道的一個秘密函式生成一個 cookie，并把 cookie 作為序列號回應給客戶端，
??如果客戶端是正常建立連接，將會回傳一個確認欄位為 cookie + 1 的報文段，接下來服務器會根據確認報文的源 Id，目的 Id，埠號以及秘密函式計算出一個結果，如果結果的值 + 1 等于確認欄位的值，則證明是剛剛請求連接的客戶端，這時候才為該 TCP 分配資源

Q：TCP三次握手中，最后一次回復丟失，會發生什么？

??如果最后一次ACK在網路中丟失，那么Server端（服務端）該TCP連接的狀態仍為SYN_RECV，并且根據 TCP的超時重傳機制依次等待3秒、6秒、12秒后重新發送 SYN+ACK 包，以便 Client（客戶端）重新發送ACK包
如果重發指定次數后，仍然未收到ACK應答，那么一段時間后，Server（服務端）自動關閉這個連接
但是Client（客戶端）認為這個連接已經建立，如果Client（客戶端）端向Server（服務端）發送資料，Server端（服務端）將以RST包（Reset，標示復位，用于例外的關閉連接）回應，此時，客戶端知道第三次握手失敗；

Q：為什么連接的時候是三次握手，關閉的時候卻是四次握手？

??建立連接的時候， 服務器在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端，
??關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送資料了但是還能接收資料，而自己也未必全部資料都發送給對方了,所以服務器可以立即關閉，也可以發送一些資料給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，服務器ACK和FIN一般都會分開發送，從而導致多了一次，

Q：為什么TCP揮手每兩次中間有一個 FIN-WAIT2等待時間？

??主動關閉的一端呼叫完close以后（即發FIN給被動關閉的一端， 并且收到其對FIN的確認ACK）則進入FIN_WAIT_2狀態，如果這個時候因為網路突然斷掉、被動關閉的一段宕機等原因，導致主動關閉的一端不能收到被動關閉的一端發來的FIN（防止對端不發送關閉連接的FIN包給本端），這個時候就需要FIN_WAIT_2定時器， 如果在該定時器超時的時候，還是沒收到被動關閉一端發來的FIN，那么直接釋放這個鏈接，進入CLOSE狀態；

Q：為什么客戶端最后還要等待2MSL？為什么還有個TIME-WAIT的時間等待？

??保證客戶端發送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，服務器已經發送了FIN+ACK報文，請求斷開，客戶端卻沒有回應，于是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器，
??防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中，客戶端發送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網路中消失，這樣新的連接中不會出現舊連接的請求報文，
??2MSL，最大報文生存時間，一個MSL 30 秒，2MSL = 60s

Q：客戶端 TIME-WAIT 狀態過多會產生什么后果？怎樣處理？

??作為服務器，短時間內關閉了大量的Client連接，就會造成服務器上出現大量的TIME_WAIT連接，占據大量的tuple /tApl/ ，嚴重消耗著服務器的資源，此時部分客戶端就會顯示連接不上；作為客戶端，短時間內大量的短連接，會大量消耗的Client機器的埠，畢竟埠只有65535個，埠被耗盡了，后續就無法在發起新的連接了；
??在高并發短連接的TCP服務器上，當服務器處理完請求后立刻主動正常關閉連接，這個場景下會出現大量socket處于TIME_WAIT狀態，如果客戶端的并發量持續很高，此時部分客戶端就會顯示連接不上
??高并發可以讓服務器在短時間范圍內同時占用大量埠，而埠有個0~65535的范圍，并不是很多，刨除系統和其他服務要用的，剩下的就更少了；短連接表示“業務處理+傳輸資料的時間 遠遠小于 TIMEWAIT超時的時間”的連接

解決方法：

• 用負載均衡來抗這些高并發的短請求；
• 服務器可以設定 SO_REUSEADDR 套接字選項來避免 TIME_WAIT狀態，TIME_WAIT 狀態可以通過優化服務器引數得到解決，因為發生TIME_WAIT的情況是服務器自己可控的，要么就是對方連接的例外，要么就是自己沒有迅速回收資源，總之不是由于自己程式錯誤導致的；
• 強制關閉，發送 RST 包越過TIMEWAIT狀態，直接進入CLOSED狀態；

Q：服務器出現了大量 CLOSE_WAIT 狀態如何解決？

??大量 CLOSE_WAIT 表示程式出現了問題，對方的 socket 已經關閉連接，而我方忙于讀或寫沒有及時關閉連接，需要檢查代碼，特別是釋放資源的代碼，或者是處理請求的執行緒配置，

Q：服務端會有一個TIME_WAIT狀態嗎？如果是服務端主動斷開連接呢？

??發起連接的主動方基本都是客戶端，但是斷開連接的主動方服務器和客戶端都可以充當，也就是說，只要是主動斷開連接的，就會有 TIME_WAIT狀態；四次揮手是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開，在socket編程中，這一程序由客戶端或服務端任一方執行close來觸發；由于TCP連接時全雙工的，因此，每個方向的資料傳輸通道都必須要單獨進行關閉，

TIME_CLOSE 和 TIME_WAIT 的狀態和意義
TIME_WAIT

??TIME_WAIT 是主動關閉連接時形成的，等待2MSL時間，約4分鐘，主要是防止最后一個ACK丟失， 由于TIME_WAIT 的時間會非常長，因此server端應盡量減少主動關閉連接；

CLOSE_WAIT
??CLOSE_WAIT是被動關閉連接是形成的，根據TCP狀態機，服務器端收到客戶端發送的FIN，則按照TCP實作發送ACK，因此進入CLOSE_WAIT狀態，但如果服務器端不執行close()，就不能由CLOSE_WAIT遷移到LAST_ACK，則系統中會存在很多CLOSE_WAIT狀態的連接，此時，可能是系統忙于處理讀、寫操作，而未將已收到FIN的連接，進行close，此時，recv/read已收到FIN的連接socket，會回傳0，

為什么需要 TIME_WAIT 狀態？
??假設最終的ACK丟失，server將重發FIN，client 必須維護TCP狀態資訊以便可以重發最終的ACK，否則會發送RST，結果server認為發生錯誤，TCP實作必須可靠地終止連接的兩個方向(全雙工關閉)，client必須進入 TIME_WAIT 狀態，因為client可能面 臨重發最終ACK的情形；

TCP 如何保證可靠傳輸

TCP協議保證資料傳輸可靠性的方式主要有：

1. 校驗和
??計算方式：在資料傳輸的程序中，將發送的資料段都當做一個16位的整數，將這些整數加起來，并且前面的進位不能丟棄，補在后面，最后取反，得到校驗和，
發送方：在發送資料之前計算檢驗和，并進行校驗和的填充，
接收方：收到資料后，對資料以同樣的方式進行計算，求出校驗和，與發送方的進行比對，

??注意：如果接收方比對校驗和與發送方不一致，那么資料一定傳輸有誤，但是如果接收方比對校驗和與發送方一致，資料不一定傳輸成功，

2. 確認應答和序列號
序列號：TCP傳輸時將每個位元組的資料都進行了編號，這就是序列號，
確認應答：TCP傳輸的程序中，每次接收方收到資料后，都會對傳輸方進行確認應答，也就是發送ACK報文，這個ACK報文當中帶有對應的確認序列號，告訴發送方，接收到了哪些資料，下一次的資料從哪里發，

確認應答=序列號結尾+1，即告訴它下一次發送資料要從這里發起；

??序列號的作用不僅僅是應答的作用，有了序列號能夠將接收到的資料根據序列號排序，并且去掉重復序列號的資料，這也是TCP傳輸可靠性的保證之一；

3. 超時重傳
??在進行TCP傳輸時，由于確認應答與序列號機制，也就是說發送方發送一部分資料后，都會等待接收方發送的ACK報文，并決議ACK報文，判斷資料是否傳輸成功，如果發送方發送完資料后，遲遲沒有等到接收方的ACK報文，這該怎么辦呢？而沒有收到ACK報文的原因可能是什么呢？

??首先，發送方沒有介紹到回應的ACK報文原因可能有兩點：

1. 資料在傳輸程序中由于網路原因等直接全體丟包，接收方根本沒有接收到；
2. 接收方接收到了回應的資料，但是發送的ACK報文回應卻由于網路原因丟包了；

??TCP在解決這個問題的時候引入了一個新的機制，叫做超時重傳機制，簡單理解就是發送方在發送完資料后等待一個時間，時間到達沒有接收到ACK報文，那么對剛才發送的資料進行重新發送，如果是剛才第一個原因，接收方收到二次重發的資料后，便進行ACK應答，如果是第二個原因，接收方發現接收的資料已存在（判斷存在的根據就是序列號，所以上面說序列號還有去除重復資料的作用），那么直接丟棄，仍舊發送ACK應答，
??那么發送方發送完畢后等待的時間是多少呢？如果這個等待的時間過長，那么會影響TCP傳輸的整體效率，如果等待時間過短，又會導致頻繁的發送重復的包，如何權衡？
??由于TCP傳輸時保證能夠在任何環境下都有一個高性能的通信，因此這個最大超時時間（也就是等待的時間）是動態計算的，
??在Linux中（BSD Unix和Windows下也是這樣）超時以500ms為一個單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍，重發一次后，仍未回應，那么等待2500ms的時間后，再次重傳，等待4500ms的時間繼續重傳，以一個指數的形式增長，累計到一定的重傳次數，TCP就認為網路或者對端出現例外，強制關閉連接，

4. 連接管理
??接管理就是三次握手與四次揮手的程序；保證可靠的連接，是保證可靠性的前提，
5. 流量控制
??收端在接收到資料后，對其進行處理，如果發送端的發送速度太快，導致接收端的結束緩沖區很快的填充滿了，此時如果發送端仍舊發送資料，那么接下來發送的資料都會丟包，繼而導致丟包的一系列連鎖反應，超時重傳呀什么的，而TCP根據接收端對資料的處理能力，決定發送端的發送速度，這個機制就是流量控制；

??在TCP協議的報頭資訊當中，有一個16位欄位的視窗大小，在介紹這個視窗大小時我們知道，視窗大小的內容實際上是接收端接收資料緩沖區的剩余大小，這個數字越大，證明接收端接識訓沖區的剩余空間越大，網路的吞吐量越大，接收端會在確認應答發送ACK報文時，將自己的即時視窗大小填入，并跟隨ACK報文一起發送過去，而發送方根據ACK報文里的視窗大小的值的改變進而改變自己的發送速度，如果接收到視窗大小的值為0，那么發送方將停止發送資料，并定期的向接收端發送視窗探測資料段，讓接收端把視窗大小告訴發送端，

6. 擁塞控制
??TCP傳輸的程序中，發送端開始發送資料的時候，如果剛開始就發送大量的資料，那么就可能造成一些問題，網路可能在開始的時候就很擁堵，如果給網路中在扔出大量資料，那么這個擁堵就會加劇，擁堵的加劇就會產生大量的丟包，就對大量的超時重傳，嚴重影響傳輸，

TCP的四種擁塞控制演算法
1.慢開始
2.擁塞控制
3.快重傳
4.快恢復
假定：
1.資料是單方向傳送，而另一個方向只傳送確認
2.接收方總是有足夠大的快取空間，因而發送發發送視窗的大小由網路的擁塞程度來決定
3.以TCP報文段的個數為討論問題的單位，而不是以位元組為單位

??傳輸輪次：發送方給接收方發送資料報文段后，接收方給發送方發回相應的確認報文段，一個傳輸輪次所經歷的時間就是往返時間RTT(RTT并非是恒定的數值），使用傳輸輪次是為了強調，把擁塞視窗cwnd所允許發送的報文段都連續發送出去，并收到了對已發送的最后一個報文段的確認，擁塞視窗cwnd會隨著網路擁塞程度以及所使用的擁塞控制演算法動態變化，

??在tcp雙方建立邏輯鏈接關系時， 擁塞視窗cwnd的值被設定為1，還需設定慢開始門限ssthresh,在執行慢開始演算法時，發送方每收到一個對新報文段的確認時，就把擁塞視窗cwnd的值加一，然后開始下一輪的傳輸，當擁塞視窗cwnd增長到慢開始門限值時，就使用擁塞避免演算法，

慢開始：
??假設當前發送方擁塞視窗cwnd的值為1，而發送視窗swnd等于擁塞視窗cwnd，因此發送方當前只能發送一個資料報文段（擁塞視窗cwnd的值是幾，就能發送幾個資料報文段），接收方收到該資料報文段后，給發送方回復一個確認報文段，發送方收到該確認報文后，將擁塞視窗的值變為2，發送方此時可以連續發送兩個資料報文段，接收方收到該資料報文段后，給發送方一次發回2個確認報文段，發送方收到這兩個確認報文后，將擁塞視窗的值加2變為4，發送方此時可連續發送4個報文段，接收方收到4個報文段后，給發送方依次回復4個確認報文，發送方收到確認報文后，將擁塞視窗加4，置為8，發送方此時可以連續發送8個資料報文段，接收方收到該8個資料報文段后，給發送方一次發回8個確認報文段，發送方收到這8個確認報文后，將擁塞視窗的值加8變為16；
??即慢開始階段的擁塞視窗呈指數增長；

當前的擁塞視窗cwnd的值已經等于慢開始門限值，之后改用擁塞避免演算法，

擁塞避免：
??也就是每個傳輸輪次，擁塞視窗cwnd只能線性加一，而不是像慢開始演算法時，每個傳輸輪次，擁塞視窗cwnd按指數增長，同理，16+1……直至到達24，假設24個報文段在傳輸程序中丟失4個，接收方只收到20個報文段，給發送方依次回復20個確認報文段，一段時間后，丟失的4個報文段的重傳計時器超時了，發送發判斷可能出現擁塞，更改cwnd和ssthresh.并重新開始慢開始演算法，如圖所示：

快速重傳：

快恢復：

??擁塞控制是TCP在傳輸時盡可能快的將資料傳輸，并且避免擁塞造成的一系列問題，是可靠性的保證，同時也是維護了傳輸的高效性，

CRC 回圈校驗的演算法

??回圈冗余校驗（Cyclic Redundancy Check， CRC）是一種根據網路資料包或電腦檔案等資料產生簡短固定位數校驗碼的一種散列函式，主要用來檢測或校驗資料傳輸或者保存后可能出現的錯誤，它是利用除法及余數的原理來作錯誤偵測的，

??在資料傳輸程序中，無論傳輸系統的設計再怎么完美，差錯總會存在，這種差錯可能會導致在鏈路上傳輸的一個或者多個幀被破壞（出現位元差錯，0變為1，或者1變為0），從而接受方接收到錯誤的資料，為盡量提高接受方收到資料的正確率，在接收方接收資料之前需要對資料進行差錯檢測，當且僅當檢測的結果為正確時接收方才真正收下資料，檢測的方式有多種，常見的有奇偶校驗、因特網校驗和回圈冗余校驗等，


??接收到的資訊為101101001，生成多項式為G(x)= x³+ x²+1，判斷傳輸是否誤碼；就拿101101001除以1101，因為之前余數為001，所以這個如果沒有差錯，必然會整除從而使得余數為0，即沒有誤碼；如果余數不為0，說明存在誤碼；

如何使用 UDP 實作可靠傳輸

??UDP不屬于連接協議，具有資源消耗少，處理速度快的優點，所以通常音頻，視頻和普通資料在傳送時，使用UDP較多，因為即使丟失少量的包，也不會對接受結果產生較大的影響;

??傳輸層無法保證資料的可靠傳輸，只能通過應用層來實作了，實作的方式可以參照tcp可靠性傳輸的方式，只是實作不在傳輸層，實作轉移到了應用層，

??最簡單的方式是在應用層模仿傳輸層TCP的可靠性傳輸，下面不考慮擁塞處理，可靠UDP的簡單設計，

1、添加seq/ack機制，確保資料發送到對端
2、添加發送和接識訓沖區，主要是用戶超時重傳，
3、添加超時重傳機制，

??詳細說明：送端發送資料時，生成一個隨機seq=x，然后每一片按照資料大小分配seq，資料到達接收端后接收端放入快取，并發送一個ack=x的包，表示對方已經收到了資料，發送端收到了ack包后，洗掉緩沖區對應的資料，時間到后，定時任務檢查是否需要重傳資料，

目前有如下開源程式利用udp實作了可靠的資料傳輸，分別為RUDP、RTP、UDT，

1、RUDP（Reliable User Datagram Protocol）
??RUDP 提供一組資料服務質量增強機制，如擁塞控制的改進、重發機制及淡化服務器演算法等，從而在包丟失和網路擁塞的情況下， RTP 客戶機（實時位置）面前呈現的就是一個高質量的 RTP 流，在不干擾協議的實時特性的同時，可靠 UDP 的擁塞控制機制允許 TCP 方式下的流控制行為，

2、RTP（Real Time Protocol）
??RTP為資料提供了具有實時特征的端對端傳送服務，如在組播或單播網路服務下的互動式視頻音頻或模擬資料，應用程式通常在 UDP 上運行 RTP 以便使用其多路結點和校驗服務；這兩種協議都提供了傳輸層協議的功能，但是 RTP 可以與其它適合的底層網路或傳輸協議一起使用，如果底層網路提供組播方式，那么 RTP 可以使用該組播表傳輸資料到多個目的地，

??RTP 本身并沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴于底層服務去實作這一程序， RTP 并不保證傳送或防止無序傳送，也不確定底層網路的可靠性， RTP 實行有序傳送， RTP 中的序列號允許接收方重組發送方的包序列，同時序列號也能用于決定適當的包位置，例如：在視頻解碼中，就不需要順序解碼，

3、UDT（UDP-based Data Transfer Protocol）
??基于UDP的資料傳輸協議（UDP-basedData Transfer Protocol，簡稱UDT）是一種互聯網資料傳輸協議，UDT的主要目的是支持高速廣域網上的海量資料傳輸，而互聯網上的標準資料傳輸協議TCP在高帶寬長距離網路上性能很差，

??顧名思義，UDT建于UDP之上，并引入新的擁塞控制和資料可靠性控制機制，UDT是面向連接的雙向的應用層協議，它同時支持可靠的資料流傳輸和部分可靠的資料報傳輸，由于UDT完全在UDP上實作，它也可以應用在除了高速資料傳輸之外的其它應用領域，例如點到點技術（P2P），防火墻穿透，多媒體資料傳輸等等；

HTTPs 與 HTTP

HTTP連接管理

搭載 HTTP 的 TCP
??HTTP 這個應用層協議是以 TCP 為基礎來傳輸資料的，當你想訪問一個資源（資源在網路中就是一個 URL）時，你需要先決議這個資源的 IP 地址和埠號，從而和這個 IP 和埠號所在的服務器建立 TCP 連接，然后 HTTP 客戶端發起服務請求（GET）報文，服務器對服務器的請求報文做出回應，等到不需要交換報文時，客戶端會關閉連接，下面我用圖很好的說明了這個程序；

??上面這幅圖很好的說明了 HTTP 從建立連接開始 -> 發起請求報文 -> 關閉連接的全程序，但是上面這個程序還忽略了一個很重要的點，那就是TCP 建立連接的程序，

??由于 HTTP 位于 TCP 的上層，所以 HTTP 的請求 -> 回應程序的時效性（性能）很大程度上取決于底層 TCP 的性能，只有在了解了 TCP 連接的性能之后，才可以更好的理解 HTTP 連接的性能，從而才能夠實作高性能的 HTTP 應用程式，

通常把一次完整的請求 -> 相應程序稱之為 HTTP 事務，

HTTP 時延損耗

從圖中可以看出，主要是有下面這幾個因素影響 HTTP 事務的時延：

1. 客戶端會根據 URL 確定服務器的 IP 和埠號，這里主要是 DNS 把域名轉換為 IP 地址的時延，DNS 會發起 DNS 查詢，查詢服務器的 IP 地址，
2. 第二個時延是 TCP 建立連接時會由客戶端向服務器發送連接請求報文，并等待服務器回送回應報文的時延，每條新的 TCP 連接建立都會有建立時延，
3. 一旦連接建立后，客戶端就會向服務器請求資料，這個時延主要是服務器從 TCP 連接中讀取請求報文，并對請求進行處理的時延，
4. 服務器會向客戶端傳輸回應報文的時延，
5. 最后一個時延是 TCP 連接關閉的時延，

??試想一個問題，假設一個頁面有五個資源（元素），每個資源都需要客戶端打開一個 TCP 連接、獲取資源、斷開連接，而且每個連接都是串行打開的，如下圖所示：

??串行的意思就是，這五個連接必須是有先后順序，不會出現同時有兩個以上的連接同時打開的情況，

??上面五個資源就需要打開五條連接，資源少還好說，CPU 能夠處理，如果頁面資源達到上百或者更多的時候呢？每個資源還需要單獨再打開一條連接嗎？這樣顯然會急劇增加 CPU 的處理壓力，造成大量的時延，顯然是沒有必要的，

??串行還有一個缺點就是，有些瀏覽器在物件加載完畢之前是無法知道物件的尺寸（size）的，并且瀏覽器需要物件尺寸資訊來將他們放在螢屏中合理的位置上，所以在加載了足夠多的物件之前，螢屏是不會顯示任何內容的，這就會造成，其實物件一直在加載，但是我們以為瀏覽器卡住了，

所以，怎么優化 HTTP 性能的方式呢？
1. 并行連接
??這是一種最常見的，也是最容易想到的一種連接方式，HTTP 允許客戶端打開多條連接，并行執行多個 HTTP 事務，加入并行連接后，整個 HTTP 事務的請求程序是這樣的，類似于流水線，我在回應連接1時連接2可以發起請求；

??采用并行連接這種方式會克服單條連接的空載時間和帶寬限制，因為每個事務都有連接，因此時延能夠重疊起來，會提高頁面的加載速度，

??但是并行連接并不一定快，如果帶寬不夠的情況下，甚至頁面回應速度還不如串行連接，因為在并行連接中，每個連接都會去競爭使用有效的帶寬，每個物件都會以較慢的速度加載，有可能連接 1 加載了 95% ，連接 2 占用帶寬加載了 80%，連接 3 ，連接 4 ，，，，，，雖然每個物件都在加載，但是頁面上卻沒有任何回應，

??而且，打開大量連接會消耗很多記憶體資源，從而出現性能問題，上面討論的就五個連接，這個還比較少，復雜的 web 頁面有可能會有數十甚至數百個內嵌物件，也就是說，客戶端可以打開數百個連接，而且有許多的客戶端同時發出申請，這樣很容易會成為性能瓶頸，

??這樣看來，并行連接并不一定"快"，實際上并行連接并沒有加快頁面的傳輸速度，并行連接也只是造成了一種假象，這是一切并行的通病，

2. 持久連接
??Web 客戶端通常會打開到同一個站點的連接，而且初始化了對某服務器請求的應用程式很可能會在不久的將來對這臺服務器發起更多的請求，比如獲取更多的圖片，這種特性被稱為站點區域性(site locality)，

??因此，HTTP 1.1 以及 HTTP1.0 的允許 HTTP 在執行完一次事務之后將連接繼續保持在打開狀態，這個打開狀態其實指的就是 TCP 的打開狀態，以便于下一次的 HTTP 事務能夠復用這條連接，

在一次 HTTP 事務結束之后仍舊保持打開狀態的 TCP 連接被稱為持久連接，

??非持久連接會在每個事務結束之后關閉，相對的，持久連接會在每個事務結束之后繼續保持打開狀態，持久連接會在不同事務之間保持打開狀態，直到客戶端或者服務器決定將其關閉為止，

??長連接也是有缺點的，如果單一客戶端發起請求數量不是很頻繁，但是連接的客戶端卻有很多的話，服務器早晚會有崩潰的時候，

??持久連接一般有兩種選型方式，一種是 HTTP 1.0 + keep-alive ；一種是 HTTP 1.1 + persistent，

??HTTP 1.1 之前的版本默認連接都是非持久連接，如果想要在舊版本的 HTTP 上使用持久連接，需要指定 Connection 的值為 Keep-Alive，

??HTTP 1.1 版本都是持久性連接，如果想要斷開連接時，需要指定 Connection 的值為 close，這也是我們上面說的兩種選型方式的版本因素，

下面是使用了持久連接之后的 HTTP 事務與使用串行 HTTP 事務連接的對比圖：

??這張圖對比了 HTTP 事務在串行連接上和持久連接的時間損耗圖，可以看到，HTTP 持久連接省去了連接打開 - 連接關閉的時間，所以在時間損耗上有所縮減，

??在持久性連接中，還有一個非常有意思的地方，就是 Connection 選項，Connection 是一個通用選項，也就是客戶端和服務端都具有的一個標頭，下面是一個具有持久性連接的客戶端和服務端的請求-回應圖

??從這張圖可以看出，持久連接主要使用的就是 Connection 標頭，這也就意味著，Connection 就是持久性連接的實作方式，

Connection 標頭
Connection 標頭具有兩種作用

• 和 Upgrade 一起使用進行協議升級
  也就是說，客戶端發起 Connection:upgrade 就表明這是一個連接升級的請求，如果服務器決定升級這次連接，就會回傳一個 101 Switching Protocols 回應狀態碼，和一個要切換到的協議的頭部欄位 Upgrade，如果服務器沒有（或者不能）升級這次連接，它會忽略客戶端發送的 Upgrade 頭部欄位，回傳一個常規的回應：例如回傳 200，
• 管理持久連接
  我們上面說持久連接有兩種方式，一種是 HTTP 1.0 + Keep-Alive ；一種是 HTTP 1.1 + persistent，

Connection: Keep-Alive
Keep-Alive: timeout=10,max=500

??在 HTTP 1.0 + Keep-Alive 這種方式下，客戶端可以通過包含 Connection：Keep-Alive 首部請求將一條連接保持在打開狀態，

??這里需要注意??一點：Keep-Alive 首部只是將請求保持在活躍狀態，發出 Keep-Alive 請求之后，客戶端和服務器不一定會同意進行 Keep-Alive 會話，它們可以在任何時刻關閉空閑的 Keep-Alive 連接，并且客戶端和服務器可以限制 Keep-Alive 連接所處理事務的數量，

??Keep-Alive 這個標頭有下面幾種選項：

• timeout：這個引數估計了服務器希望將連接保持在活躍狀態的時間，
• max ：這個引數是跟在 timeout 引數后面的，它表示的是服務器還能夠為多少個事務打開持久連接，
• Keep-Alive 這個首部是可選的，但是只有在提供 Connection：Keep-Alive 時才能使用它，

Keep-Alive 使用限制和規則
??在 HTTP/1.0 中，Keep-Alive 并不是默認使用的，客戶端必須發送一個 Connection：Keep-Alive 請求首部來激活 Keep-Alive 連接，

??通過檢測回應中是否含有 Connection：Keep-Alive 首部欄位，客戶端可以判斷服務器是否在發出回應之后關閉連接，

??代理和網管必須執行 Connection 首部規則，它們必須在將報文轉發出去或者將快取之前，洗掉 Connection 首部中的首部欄位和 Connection 首部自身，因為 Connection 是一個 Hop-by-Hop 首部，這個首部說的是只對單次轉發有效，會因為轉發給快取/代理服務器而失效，

??嚴格來說，不應該與無法確定是否支持 Connection 首部的代理服務器建立 Keep-Alive 連接，以防止出現啞代理問題；

代理服務器

代理服務器就是代替客戶端去獲取網路資訊的一種媒介，通俗一點就是網路資訊的中轉站，

為什么我們需要代理服務器？

??最廣泛的一種用處是我們需要使用代理服務器來替我們訪問一些我們客戶端無法直接訪問的網站，除此之外，代理服務器還有很多功能，比如快取功能，可以降低費用，節省帶寬；對資訊的實時監控和過濾，代理服務器相對于目標服務器（最侄訓取資訊的服務器）來說，也是一個客戶端，它能夠獲取服務器提供的資訊，代理服務器相對于客戶端來說，它是一個服務器，由它來決定提供哪些資訊給客戶端，以此來達到監控和過濾的功能，

啞代理問題
??啞代理問題主要是，http客戶端和服務器端進行通信時，會經過代理服務器，但是代理服務器不一定支持keep-alive，

啞代理問題出現就出現在代理服務器上，再細致一點就是出現在不能識別 Connection 首部的代理服務器，而且不知道在發出請求之后會洗掉 Connection 首部的代理服務器；
Proxy-Connection 解決啞代理
??網景公司提出了一種使用 Proxy-Connection 標頭的辦法，首先瀏覽器會向代理發送 Proxy-Connection 擴展首部，而不是官方支持的 Connection 首部，如果代理服務器是啞代理的話，它會直接將 Proxy-Connection 發送給服務器，而服務器收到 Proxy-Connection 的話，就會忽略這個首部，這樣不會帶來任何問題，如果是一個聰明的代理服務器，在收到 Proxy-Connection 的時候，就會直接將 Connection 替換掉 Proxy-Connection ，再發送給服務器，
HTTP/1.1 持久連接
??HTTP/1.1 逐漸停止了對 Keep-Alive 連接的支持，用一種名為 persistent connection 的改進型設計取代了 Keep-Alive ，這種改進型設計也是持久連接，不過比 HTTP/1.0 的作業機制更優，

??與 HTTP/1.0 的 Keep-Alive 連接不同，HTTP/1.1 在默認情況下使用的就是持久連接，除非特別指明，否則 HTTP/1.1 會假定所有連接都是持久連接，如果想要在事務結束后關閉連接的話，就需要在報文中顯示添加一個 Connection：close 首部，這是與以前的 HTTP 協議版本很重要的區別，

??使用 persistent connection 也會有一些限制和規則：

• 首先，發送了 Connection: close 請求后，客戶端就無法在這條連接上發送更多的請求，這同時也可以說，如果客戶端不想發送其他請求，就可以使用 Connection：close 關閉連接，
• HTTP/1.1 的代理必須能夠分別管理客戶端和服務器的持久連接 ，每個持久連接都只適用于單次傳輸，
• 客戶端對任何服務器或者代理最好只維護兩條持久連接，以防止服務器過載，
• 只有物體部分的長度和相應的 Content-Length保持一致時，或者使用分塊傳輸編碼的方式時，連接才能保持長久，

管道化連接
??HTTP/1.1 允許在持久連接上使用請求管道，這是相對于 Keep-Alive 連接的又一個性能優化，管道就是一個承載 HTTP 請求的載體，我們可以將多個 HTTP 請求放入管道，這樣能夠降低網路的環回時間，提升性能，下圖是使用串行連接、并行連接、管道化連接的示意圖：

??使用管道化的連接也有幾處限制：

• 如果 HTTP 客戶端無法確認連接是持久的，就不應該使用管道，
• 必須按照與請求的相同順序回送 HTTP 回應，因為 HTTP 沒有序號這個概念，所以一旦回應失序，就沒辦法將其與請求匹配起來了，
• HTTP 客戶端必須做好連接會在任何時刻關閉的準備，還要準備好重發所有未完成的管道化請求，

HTTP 關閉連接
??所有 HTTP 客戶端、服務器或者代理都可以在任意時刻關閉一條 HTTP 傳輸連接，通常情況下會在一次回應后關閉連接，但是保不準也會在 HTTP 事務的程序中出現，

??但是，服務器無法確定在關閉的那一刻，客戶端有沒有資料要發送，如果出現這種情況，客戶端就會在進行資料傳輸的程序中發生了寫入錯誤，

??即使在不出錯的情況下，連接也可以在任意時刻關閉，如果在事務傳輸的程序中出現了連接關閉情況，就需要重新打開連接進行重試，如果是單條連接還好說，如果是管道化連接，就比較糟糕，因為管道化連接會把大量的連接丟在管道中，此時如果服務器關閉，就會造成大量的連接未回應，需要重新調度，

??如果一個 HTTP 事務不管執行一次還是執行 n 次，它得到的結果始終是一樣的，那么我們就認為這個事務是冪等的，一般 GET、HEAD、PUT、DELETE、TRACE 和 OPTIONS方法都認為是冪等的，客戶端不應該以管道化的方式發送任何非冪等請求，比如 POST，否則就會造成不確定的后果，

??由于 HTTP 使用 TCP 作為傳輸層的協議，所以 HTTP 關閉連接其實還是 TCP 關閉連接的程序，

HTTP 關閉連接一共分為三種情況：完全關閉、半關閉和正常關閉，

??應用程式可以關閉 TCP 輸入和輸出信道中的任何一個，或者將二者同時關閉，呼叫套接字 close() 方法會講輸入和輸出同時關閉，這就被稱為完全關閉，還可以呼叫套接字的 shutdown 方法單獨關閉輸入或者輸出信道，這被稱為半關閉，HTTP 規范建議當客戶端和服務器突然需要關閉連接的時候，應該正常關閉，但是它沒有說如何去做，

參考文章：https://mp.weixin.qq.com/s/MksdIMNCdL4CRfJS5Q-gMQ

HTTPS 與 HTTP的區別

??HTTP：是互聯網上應用最為廣泛的一種網路協議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少，

??HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL，

??HTTPS協議的主要作用可以分為兩種：一種是建立一個資訊安全通道，來保證資料傳輸的安全；另一種就是確認網站的真實性，

??HTTP協議傳輸的資料都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私資訊非常不安全，為了保證這些隱私資料能加密傳輸，于是網景公司設計了SSL（Secure Sockets Layer）協議用于對HTTP協議傳輸的資料進行加密，從而就誕生了HTTPS，簡單來說，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全，

HTTPS和HTTP的區別主要如下：

1. https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用，
2. http是超文本傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議，
3. http和https使用的是完全不同的連接方式，用的埠也不一樣，前者是80，后者是443，
4. http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全，

HTTPS 的原理，客戶端為什么信任第三方證書

客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟，如圖所示，
（1）客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接，
（2）Web服務器收到客戶端請求后，會將網站的證書資訊（證書中包含公鑰）傳送一份給客戶端，
（3）客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級，也就是資訊加密的等級，
（4）客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然后利用網站的公鑰將會話密鑰加密，并傳送給網站，
（5）Web服務器利用自己的私鑰解密出會話密鑰，
（6）Web服務器利用會話密鑰加密與客戶端之間的通信，

Q：HTTPS 客戶端驗證 服務端證書流程
證書預置和申請
1：客戶端瀏覽器會預置根證書， 里面包含CA公鑰
2：服務器去CA申請一個證書
3： CA用自己的簽名去簽一個證書，指紋資訊保存在證書的數字摘要里面， 然后發送給服務器

一次訪問流程（簡化）
1： 客戶端 sayHello
2： 服務器回傳證書
3-1： 客戶端驗證證書內容有效性（過期時間， 域名是否相同等）
3-2： 驗證證書的有效性 （是否被串改）， 通過本地根證書的CA公鑰解密數字摘要，看是否匹配，
3-3：如果數字簽名驗證通過， 就可以使用服務器證書里面提供的公鑰進行下一步通信，

https優點
??盡管HTTPS并非絕對安全，掌握根證書的機構、掌握加密演算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，主要有以下幾個好處：
（1）使用HTTPS協議可認證用戶和服務器，確保資料發送到正確的客戶機和服務器；
（2）HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全，可防止資料在傳輸程序中不被竊取、改變，確保資料的完整性，
（3）HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本，
（4）谷歌曾在2014年8月份調整搜索引擎演算法，并稱“比起同等HTTP網站，采用HTTPS加密的網站在搜索結果中的排名將會更高”，

https缺點
雖然說HTTPS有很大的優勢，但其相對來說，還是存在不足之處的：
（1）HTTPS協議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；
（2）HTTPS連接快取不如HTTP高效，會增加資料開銷和功耗，甚至已有的安全措施也會因此而受到影響；
（3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用，
（4）SSL證書通常需要系結IP，不能在同一IP上系結多個域名，IPv4資源不可能支撐這個消耗，
（5）HTTPS協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用，最關鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行，

HTTP 方法

HTTP/1.1協議中共定義了八種方法（有時也叫“動作”），來表明Request-URL指定的資源不同的操作方式；
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法；
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法；

1、OPTIONS
回傳服務器針對特定資源所支持的HTTP請求方法，也可以利用向web服務器發送‘*’的請求來測驗服務器的功能性
2、HEAD
向服務器索與GET請求相一致的回應，只不過回應體將不會被回傳，這一方法可以再不必傳輸整個回應內容的情況下，就可以獲取包含在回應小訊息頭中的元資訊，
3、GET
向特定的資源發出請求，注意：GET方法不應當被用于產生“副作用”的操作中，例如在Web Application中，其中一個原因是GET可能會被網路蜘蛛等隨意訪問，Loadrunner中對應get請求函式：web_link和web_url
4、POST
向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案），資料被包含在請求體中，POST請求可能會導致新的資源的建立和/或已有資源的修改， Loadrunner中對應POST請求函式：web_submit_data,web_submit_form
5、PUT
向指定資源位置上傳其最新內容
6、DELETE
請求服務器洗掉Request-URL所標識的資源
7、TRACE
回顯服務器收到的請求，主要用于測驗或診斷
8、CONNECT
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器，

注意：
1）方法名稱是區分大小寫的，當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當回傳狀態碼405（Mothod Not Allowed）；當服務器不認識或者不支持對應的請求方法時，應回傳狀態碼501（Not Implemented），
2）HTTP服務器至少應該實作GET和HEAD/POST方法，其他方法都是可選的，此外除上述方法，特定的HTTP服務器支持擴展自定義的方法，

HTTP 請求/回應的步驟：

客戶端連接到Web服務器->發送Http請求->服務器接受請求并回傳HTTP回應->釋放連接TCP連接->客戶端瀏覽器決議HTML內容

1、客戶端連接到Web服務器
??一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP埠（默認為80）建立一個TCP套接字連接，例如，http://www.baidu.com

2、發送HTTP請求
??通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求資料4部分組成，

3、服務器接受請求并回傳HTTP回應
??Web服務器決議請求，定位請求資源，服務器將資源復本寫到TCP套接字，由客戶端讀取，一個回應由狀態行、回應頭部、空行和回應資料4部分組成，
4、釋放連接TCP連接
??若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;

5、客戶端瀏覽器決議HTML內容
??客戶端瀏覽器首先決議狀態行，查看表明請求是否成功的狀態代碼，然后決議每一個回應頭，回應頭告知以下為若干位元組的HTML檔案和檔案的字符集，客戶端瀏覽器讀取回應資料HTML，根據HTML的語法對其進行格式化，并在瀏覽器視窗中顯示，

客戶端發送一個HTTP請求到服務器的請求訊息包括以下格式
請求行（request line）、請求頭部（header）、空行和請求資料四個部分組成，

請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本
Get請求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8

第一部分：請求行，用來說明請求型別,要訪問的資源以及所使用的HTTP版本.
GET說明請求型別為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源，該行的最后一部分說明使用的是HTTP1.1版本，

第二部分：請求頭部，緊接著請求行（即第一行）之后的部分，用來說明服務器要使用的附加資訊
從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器型別檢測邏輯的重要基礎.該資訊由你的瀏覽器來定義,并且在每個請求中自動發送等等

第三部分：空行，請求頭部后面的空行是必須的
即使第四部分的請求資料為空，也必須有空行，

第四部分：請求資料也叫主體，可以添加任意的其他資料，
這個例子的請求資料為空，

POST請求例子，使用Charles抓取的request：

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明了是post請求，以及http1.1版本，
第二部分：請求頭部，第二行至第六行，
第三部分：空行，第七行的空行，
第四部分：請求資料，第八行，

HTTP請求訊息Response

??一般情況下，服務器接收并處理客戶端發過來的請求后會回傳一個HTTP的回應訊息，HTTP回應也由四個部分組成，分別是：狀態行、訊息報頭、空行和回應正文

第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態訊息 三部分組成，
第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態訊息為（ok）

第二部分：訊息報頭，用來說明客戶端要使用的一些附加資訊
第二行和第三行為訊息報頭，
Date:生成回應的日期和時間；Content-Type:指定了MIME型別的HTML(text/html),編碼型別是UTF-8

第三部分：空行，訊息報頭后面的空行是必須的
第四部分：回應正文，服務器回傳給客戶端的文本資訊，
空行后面的html部分為回應正文，

HTTP 例外狀態碼

200 OK 當您的操作將在回應正文中回傳資料時，出現此結果，

204 No Content 當您的操作成功，但不在回應正文中回傳資料時，出現此結果，

304 Not Modified（重定向） 當測驗物體自上次檢索以來是否被修改時，出現此結果，

403 Forbidden 客戶端錯誤

401 Unauthorized 客戶端錯誤

413 Payload Too Large（客戶端錯誤） 當請求長度過長時，出現此結果，

400 BadRequest（客戶端錯誤） 當引數無效時，出現此結果，

404 Not Found（客戶端錯誤） 當資源不存在時，出現此結果，

405 Method Not Allowed（客戶端錯誤）由于方法和資源組合不正確而出現此錯誤， 例如，您不能對一個物體集合使用 DELETE 或 PATCH，

412 Precondition Failed 客戶端錯誤

501 Not Implemented（服務器錯誤） 當未實施某個請求的操作時，出現此結果，

503 Service Unavailable（服務器錯誤） 當 Web API 服務不可用時，出現此結果，

GET與POST

??“get”方法提交的資料會直接填充在請求報文的URL上，如“ https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1 ” “？”問號劃分域名和get提交的引數，A=B中的A是引數名，B是引數值，多個引數之間用&進行分割，如果引數值是中文，則會轉換成諸如%ab%12加密16進制碼，一般來說，瀏覽器處理的URL最大限度長度為1024B（不同瀏覽器不一樣），所以GET方法提交引數長度有限制，

?? “post”方法提交的資料會附在正文上，一般請求正文的長度是沒有限制的，但表單中所能處理的長度一般為100k（不同協議不同瀏覽器不一樣）,而且需要考慮下層報文的傳輸效率，不推薦過長，

??所以GET方法可以用來傳輸一些可以公開的引數資訊，決議也比較方便，如百度的搜索的關鍵詞，而POST方法可以用來提交一個用戶的敏感資訊（如果不使用HTTPS加密，報文正文仍舊是明文，容易被人截獲讀取）

HTTP 長連接短連接使用場景

HTTP短連接
??在 HTTP/1.0 中默認使用短連接，也就是說，客戶端和服務器每進行一次 HTTP 操作，就建立一次連接，任務結束就中斷連接，當客戶端瀏覽器訪問的某個 HTML 或其他型別的 Web 頁中包含有其他的 Web 資源（如 JavaScript 檔案、影像檔案、CSS 檔案等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話，

HTTP長連接
??而從 HTTP/1.1 起，默認使用長連接，用以保持連接特性，使用長連接的 HTTP 協議，會在回應頭加入這行代碼：Connection:keep-alive

??在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸 HTTP 資料 的 TCP 連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接，

??Keep-Alive 不會永久保持連接，它有一個保持時間，可以在不同的服務器軟體（如 Apache）中設定這個時間，實作長連接需要客戶端和服務端都支持長連接， HTTP 協議的長連接和短連接，實質上是 TCP 協議的長連接和短連接，

長連接和短連接的應用場景
??長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況，每個 TCP 連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多， 所以每個操作完后都不斷開，下次處理時直接發送資料包就 OK 了，不用建立 TCP 連接，例如： 資料庫的連接用長連接， 如果用短連接頻繁的通信會造成 socket 錯誤，而且頻繁的 socket創建也是對資源的浪費，

??而像 WEB 網站的 http 服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的 資源，而像 WEB 網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源， 如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧，所以并發量大，但每個用戶無需頻繁操作情況下需用短連接，

ARP 攻擊

ARP協議

??ARP協議（address resolution protocol）地址決議協議；

??一臺主機和另一臺主機通信，要知道目標的IP地址，但是在局域網中傳輸資料的網卡卻不能直接識別IP地址，所以用ARP決議協議將IP地址決議成MAC地址，ARP協議的基本功能就是通過目標設備的IP地址，來查詢目標設備的mac地址，

??在局域網的任意一臺主機中，都有一個ARP快取表，里面保存本機已知的此局域網中各主機和路由器的IP地址和MAC地址的對照關系，ARP快取表的生命周期是有時限的（一般不超過20分鐘），

舉個例子：假設局域網中有四臺主機

??主機A想和主機B通信，主機A會先查詢自己的ARP快取表里有沒有B的聯系方式，有的話，就將mac-b地址封裝到資料包外面，發送出去，沒有的話，A會向全網路發送一個ARP廣播包，大聲詢問：我的IP地址是192.168.0.2，硬體地址是mac-a，我想知道IP地址是192.168.0.3的硬體地址是多少？ 此時，局域網內所有主機都收到了，B收到后會單獨私密回應：我是192.168.0.3，我的硬體地址是mac-b，其他主機不會理A的；此時A知道了B的資訊，同時也會動態的更新自身的快取表，

Q：既然ARP協議是決議ip地址到mac地址，那通訊軟體上我不知道對方的ip地址，怎么能給他發資訊？
??這就牽涉到服務器了，以QQ為例，A登陸自己的QQ就是向服務器發送登陸請求，此時服務器會核實A的賬號和密碼，并獲取它的ip地址，存在服務器中，并把自己的ip地址給A；同樣B登陸也是如此，此時服務器就有A、B二者的IP地址了，如果A發資訊給B，那么資訊會先到服務器中，然后服務器找到B的ip地址，將它發送給B；
??等于A、B的通信時通過QQ服務器進行的，A、B都不知道對方的IP地址，只知道服務器的地址，他們將資訊給服務器，由服務器來進行轉發；

ARP攻擊的發現

首先診斷是否為ARP病毒攻擊
1、當發現上網明顯變慢，或者突然掉線時，我們可以用arp -a命令來檢查ARP表：(點擊“開始”按鈕-選擇“運行”-輸入“cmd”點擊"確定"按鈕，在視窗中輸入“arp -a”命令)如果發現網關的MAC地址發生了改變，或者發現有很多IP指向同一個物理地址，那么肯定就是ARP欺騙所致，這時可以通過”arp -d“清除arp串列，重新訪問，

2、利用ARP防火墻類軟體(如：360ARP防火墻、AntiARPSniffer等)，

如何判斷交換機是否受到ARP攻擊以及處理方式

如果網路受到了ARP攻擊，可能會出現如下現象：
1、用戶掉線、頻繁斷網、上網慢、業務中斷或無法上網，
2、設備CPU占用率較高、設備托管、下掛設備掉線、設備主備狀態震蕩、設備埠指示燈紅色快閃，
3、Ping有時延、丟包或不通，

局域網內的機器遭到ARP病毒欺騙攻擊，如果找到源頭的機器，將其病毒或木馬殺掉，局域網內機器就會恢復正常，那么如何才能快速定位到攻擊的源頭機器呢?

1、用arp -a命令，當發現上網明顯變慢，或者突然掉線時，我們可以用arp -a命令來檢查ARP表，如果發現網關的MAC地址發生了改變，或者發現有很多IP地址指向同一個MAC地址，那么肯定就是ARP攻擊所致，

2、利用彩影ARP防火墻軟體查看，如果網卡是處于混雜模式或者ARP請求包發送的速度大或者ARP請求包總量非常大，判斷這臺機器有可能就是“元兇”，定位好機器后，再做病毒資訊收集作業，

3、通過路由器的“系統歷史記錄”查看，由于ARP攻擊的木馬程式發作的時候會發出大量的資料包導致局域網通訊阻塞以及其自身處理能力的限制，用戶會感覺上網速度越來越慢，當ARP攻擊的木馬程式停止運行時，用戶會恢復從路由器上網，切換程序中用戶會再斷一次線，這個訊息代表了用戶的MAC地址發生了變化，在ARP攻擊木馬開始運行的時候，局域網所有主機的MAC地址更新為病毒主機的MAC地址(即所有資訊的MAC New地址都一致為病毒主機的MAC地址)，同時在路由器的“用戶統計”中看到所有用戶的MAC地址資訊都一樣，

??如果是在路由器的“系統歷史記錄”中看到大量MAC Old地址都一致，則說明局域網內曾經出現過ARP攻擊(ARP攻擊的木馬程式停止運行時,主機在路由器上恢復其真實的MAC地址)，

ARP攻擊程序

攻擊方式
1、 簡單的詐騙攻擊

??這是對比多見的攻擊，經過發送偽造的ARP包來詐騙路由和方針主機，讓方針主機認為這是一個合法的主機，便完成了詐騙，這種詐騙多發生在同一網段內，因為路由不會把本網段的包向外轉發，當然完成不一樣網段的攻擊也有辦法，便要經過ICMP協議來告訴路由器從頭挑選路由，

2、根據ARP的DOS

??這是新呈現的一種攻擊辦法，D.O.S又稱拒絕服務攻擊，當大量的銜接請求被發送到一臺主機時，因為主機的處理才能有限，不能為正常用戶提供服務，便呈現拒絕服務，這個程序中假如運用ARP來躲藏自己，在被攻擊主機的日志上就不會呈現真實的IP攻擊，也不會影響到本機，

3、MAC Flooding

??這是一個對比風險的攻擊，能夠溢位交流機的ARP表，使全部網路不能正常通訊，

4、交流環境的嗅探

??在開始的小型局域網中咱們運用HUB來進行互連，這是一種廣播的辦法，每個包都會經過網內的每臺主機，經過運用軟體，就能夠嗅談到全部局域網的資料，現在的網路多是交流環境，網路內資料的傳輸被鎖定的特定方針，既已斷定的方針通訊主機，在ARP詐騙的根底之上，能夠把自己的主機偽形成一個中心轉發站來監聽兩臺主機之間的通訊，

ARP攻擊的防護

1、 ARP 高速快取超時設定
??在ARP高速快取中的表項一般都要設定超時值，縮短這個這個超時值能夠有用的避免ARP表的溢位，

2、 IP+MAC訪問操控 -----推薦使用
??單純依托IP或MAC來樹立信賴聯系是不安全，抱負的安全聯系樹立在IP+MAC的根底上，這也是咱們校園網上網有必要系結IP和MAC的因素之一，

3、 靜態ARP快取表
??每臺主機都有一個暫時寄存IP-MAC的對應表ARP攻擊就經過更改這個快取來到達詐騙的意圖，運用靜態的ARP來系結正確的MAC是一個有用的辦法，在命令列下運用arp -a能夠檢查當時的ARP快取表，

4、自動查詢
??在某個正常的時間，做一個IP和MAC對應的資料庫，以后定時檢查當時的IP和MAC對應聯系是否正常，定時檢查交流機的流量串列，檢查丟包率，

??ARP本省不能形成多大的損害，一旦被聯系使用，其風險性就不可估量，因為ARP自身的疑問，使得防備ARP的攻擊很棘手，經常檢查當時的網路狀況，監控流量對一個站長來說是個很好的風氣

NAT 原理

參考文章：
NAT技識訓本原理與應用

??公有IP地址：也叫全域地址，是指合法的IP地址，它是由NIC（網路資訊中心）或者ISP(網路服務提供商)分配的地址，對外代表一個或多個內部區域地址，是全球統一的可尋 址的地址，

??私有IP地址：也叫內部地址，屬于非注冊地址，專門為組織機構內部使用，因特網分配編號委員會（IANA）保留了3塊IP地址做為私有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

??地址池：地址池是有一些外部地址（全球唯一的IP地址）組合而成，我們稱這樣的一個地址集合為地址池，在內部網路的資料包通過地址轉換到達外部網路時，將會在地址池中選擇某個IP地址作為資料包的源IP地址，這樣可以有效的利用用戶的外部地址，提高訪問外部網路的能力，

NAT是什么

NAT：英文全稱是“Network Address Translation”，中文意思是“網路地址轉換”，它是一個IETF(Internet Engineering Task Force, Internet工程任務組)標準，允許一個整體機構以一個公用IP（Internet Protocol）地址出現在Internet上，顧名思義，它是一種把內部私有網路地址（IP地址）翻譯成合法網路IP地址的技術，如下圖所示，因此我們可以認為，NAT在一定程度上，能夠有效的解決公網地址不足的問題，

??簡單地說，NAT就是在局域網內部網路中使用內部地址，而當內部節點要與外部網路進行通訊時，就在網關（可以理解為出口，打個比方就像院子的門一樣）處，將內部地址替換成公用地址，從而在外部公網（internet）上正常使用，NAT可以使多臺計算機共享Internet連接，這一功能很好地解決了公共 IP地址緊缺的問題，通過這種方法，可以只申請一個合法IP地址，就把整個局域網中的計算機接入Internet中，這時，NAT屏蔽了內部網路，所有內部網計算機對于公共網路來說是不可見的，而內部網計算機用戶通常不會意識到NAT的存在，如下圖所示，這里提到的內部地址，是指在內部網路中分配給節點的私有IP地址，這個地址只能在內部網路中使用，不能被路由轉發，

??NAT 功能通常被集成到路由器、防火墻、ISDN路由器或者單獨的NAT設備中，比如Cisco路由器中已經加入這一功能，網路管理員只需在路由器的IOS中設定NAT功能，就可以實作對內部網路的屏蔽，再比如防火墻將WEB Server的內部地址192.168.1.1映射為外部地址202.96.23.11，外部訪問202.96.23.11地址實際上就是訪問訪問 192.168.1.1，此外，對于資金有限的小型企業來說，現在通過軟體也可以實作這一功能，Windows 98 SE、Windows 2000 都包含了這一功能，

NAT分類

??NAT有三種型別：靜態NAT(Static NAT)、動態地址NAT(Pooled NAT)、網路地址埠轉換NAPT（Port-Level NAT），
靜態NAT
??通過手動設定，使 Internet 客戶進行的通信能夠映射到某個特定的私有網路地址和埠，如果想讓連接在 Internet 上的計算機能夠使用某個私有網路上的服務器（如網站服務器）以及應用程式（如游戲），那么靜態映射是必需的，靜態映射不會從 NAT 轉換表中洗掉，
??如果在 NAT 轉換表中存在某個映射，那么 NAT 只是單向地從 Internet 向私有網路傳送資料，這樣，NAT 就為連接到私有網路部分的計算機提供了某種程度的保護，但是，如果考慮到 Internet 的安全性，NAT 就要配合全功能的防火墻一起使用，

??對于以上網路拓撲圖，當內網主機 10.1.1.1如果要與外網的主機201.0.0.11通信時，主機（IP：10.1.1.1）的資料包經過路由器時，路由器通過查找NAT table 將IP資料包的源IP地址（10.1.1.1）改成與之對應的全域IP地址（201.0.0.1），而目標IP地址201.0.0.11保持不變，這樣，資料包就能到達201.0.0.11，而當主機HostB(IP:201.0.0.11) 回應的資料包到達與內網相連接的路由器時，路由器同樣查找NAT table，將IP資料包的目的IP 地址改成10.1.1.1，這樣內網主機就能接收到外網主機發過來的資料包，在靜態NAT方式中，內部的IP地址與公有IP地址是一種一一對應的映射關系，所以，采用這種方式的前提是，機構能夠申請到足夠多的全域IP地址，
動態NAT
??動態地址NAT只是轉換IP地址，它為每一個內部的IP地址分配一個臨時的外部IP地址，主要應用于撥號，對于頻繁的遠程聯接也可以采用動態NAT，當遠程用戶聯接上之后，動態地址NAT就會分配給他一個IP地址，用戶斷開時，這個IP地址就會被釋放而留待以后使用，

??動態NAT方式適合于 當機構申請到的全域IP地址較少，而內部網路主機較多的情況，內網主機IP與全域IP地址是多對一的關系，當資料包進出內網時，具有NAT功能的設備對IP資料包的處理與靜態NAT的一樣，只是NAT table表中的記錄是動態的，若內網主機在一定時間內沒有和外部網路通信，有關它的IP地址映射關系將會被洗掉，并且會把該全域IP地址分配給新的IP資料包使用，形成新的NAT table映射記錄，

網路地址埠轉換NAPT
??網路地址埠轉換NAPT（Network Address Port Translation）則是把內部地址映射到外部網路的一個IP地址的不同埠上，它可以將中小型的網路隱藏在一個合法的IP地址后面，NAPT與 動態地址NAT不同，它將內部連接映射到外部網路中的一個單獨的IP地址上，同時在該地址上加上一個由NAT設備選定的埠號，

NAPT是使用最普遍的一種轉換方式，它又包含兩種轉換方式：SNAT和DNAT，

(1)源NAT（Source NAT，SNAT）：修改資料包的源地址，源NAT改變第一個資料包的來源地址，它永遠會在資料包發送到網路之前完成，資料包偽裝就是一具SNAT的例子，

(2)目的NAT（Destination NAT，DNAT）：修改資料包的目的地址，Destination NAT剛好與SNAT相反，它是改變第一個資料包的目的地地址，如平衡負載、埠轉發和透明代理就是屬于DNAT，

源NAT舉例：對于以上網路拓撲圖，內網的主機數量比較多，但是該組織只有一個合法的IP地址，當內網主機（10.1.1.3）往外發送資料包時，則需要修改資料包的IP地址和TCP/UDP埠號，例如將

源IP：10.1.1.3

源port：1493

改成

源IP：201.0.0.1

源port：1492（注意：源埠號可以與原來的一樣也可以不一樣）

當外網主機（201.0.0.11）回應內網主機（10.1.1.3）時，應將：

目的IP：201.0.0.1

目的port：1492

改成

目的IP：10.1.1.3

目的port：1493

??這樣，通過修改IP地址和埠的方法就可以使內網中所有的主機都能訪問外網，此類NAT適用于組織或機構內只有一個合法的IP地址的情況，也是動態NAT的一種特例，

??目的NAT舉例：這種方式適用于內網的某些服務器需要為外網提供某些服務的情況，例如以上拓 撲結構，內網服務器群（ip地址分別為：10.1.1.1,10.1.1.2,10.1.1.3等）需要為外網提供WEB 服務，當外網主機HostB訪問內網時，所發送的資料包的目的IP地址為10.1.1.127，埠號為：80，當該資料包到達內網連接的路由器時，路由器查找NAT table，路由器通過修改目的IP地址和埠號，將外網的資料包平均發送到不同的主機上（10.1.1.1,10.1.1.2,10.1.1.3等），這樣就實作了負載均衡，

NAT原理

地址轉換+連接跟蹤+埠轉換
地址轉換
??NAT的基本作業原理是，當私有網主機和公共網主機通信的IP包經過NAT網關時，將IP包中的源IP或目的IP在私有IP和NAT的公共IP之間進行轉換，

??如下圖所示，NAT網關有2個網路埠，其中公共網路埠的IP地址是統一分配的公共 IP，為202.20.65.5；私有網路埠的IP地址是保留地址為192.168.1.1，私有網中的主機192.168.1.2向公共網中的主機202.20.65.4發送了1個IP包(Dst=202.20.65.4,Src=192.168.1.2)，

??NAT Gateway的公共IP并轉發到公共網，此時IP包（Dst=202.20.65.4，Src=202.20.65.5）中已經不含任何私有網IP的資訊，由于IP包的源IP已經被轉換成NAT Gateway的公共IP，Web Server發出的回應IP包（Dst= 202.20.65.5,Src=202.20.65.4）將被發送到NAT Gateway，

??這時，NAT Gateway會將IP包的目的IP轉換成私有網中主機的IP，然后將IP包（Des=192.168.1.2，Src=202.20.65.4）轉發到私有網，對于通信雙方而言，這種地址的轉換程序是完全透明的，轉換示意圖如下，

??如果內網主機發出的請求包未經過NAT，那么當Web Server收到請求包，回復的回應包中的目的地址就是私有網路IP地址，在Internet上無法正確送達，導致連接失敗，
連接跟蹤
??在上述程序中，NAT Gateway在收到回應包后，就需要判斷將資料包轉發給誰，此時如果子網內僅有少量客戶機，可以用靜態NAT手工指定；但如果內網有多臺客戶機，并且各自訪問不同網站，這時候就需要連接跟蹤（connection track），如下圖所示：

??在NAT Gateway收到客戶機發來的請求包后，做源地址轉換，并且將該連接記錄保存下來，當NAT Gateway收到服務器來的回應包后，查找Track Table，確定轉發目標，做目的地址轉換，轉發給客戶機，
埠轉換
??以上述客戶機訪問服務器為例，當僅有一臺客戶機訪問服務器時，NAT Gateway只須更改資料包的源IP或目的IP即可正常通訊，但是如果Client A和Client B同時訪問Web Server，那么當NAT Gateway收到回應包的時候，就無法判斷將資料包轉發給哪臺客戶機，如下圖所示，

??如果兩客戶機訪問同一服務器的源埠不同，那么在Track Table里加入埠資訊即可區分，如果源埠正好相同，那么在實行SNAT和DNAT的同時對源埠也要做相應的轉換，如下圖所示，

NAT應用

NAT主要可以實作以下幾個功能：資料包偽裝、平衡負載、埠轉發和透明代理，

資料偽裝: 可以將內網資料包中的地址資訊更改成統一的對外地址資訊，不讓內網主機直接暴露在因特網上，保證內網主機的安全，同時，該功能也常用來實作共享上網，例如，內網主機訪問外網時，為了隱藏內網拓撲結構，使用全域地址替換私有地址，

埠轉發: 當內網主機對外提供服務時，由于使用的是內部私有IP地址，外網無法直接訪問，因此，需要在網關上進行埠轉發，將特定服務的資料包轉發給內網主機，例如公司小王在自己的服務器上架設了一個Web網站，他的IP地址為192.168.0.5，使用默認埠80，現在他想讓局域網外的用戶也能直接訪問他的Web站點，利用NAT即可很輕松的解決這個問題，服務器的IP地址為210.59.120.89，那么為小王分配一個埠，例如81，即所有訪問210.59.120.89:81的請求都自動轉向192.168.0.5:80，而且這個程序對用戶來說是透明的，

負載平衡:目的地址轉換NAT可以重定向一些服務器的連接到其他隨機選定的服務器，例如1.2.3所講的目的NAT的例子，

失效終結:目的地址轉換NAT可以用來提供高可靠性的服務，如果一個系統有一臺通過路由器訪問的關鍵服務器，一旦路由器檢測到該服務器當機，它可以使用目的地址轉換NAT透明的把連接轉移到一個備份服務器上，提高系統的可靠性，

透明代理:例如自己架設的服務器空間不足，需要將某些鏈接指向存在另外一臺服務器的空間；或者某臺計算機上沒有安裝IIS服務，但是卻想讓網友訪問該臺計算機上的內容，這個時候利用IIS的Web站點重定向即可輕松的幫助我們搞定，

NAT缺陷

??NAT在最開始的時候是非常完美的，但隨著網路的發展，各種新的應用層出不窮，此時NAT也暴露出了缺點，NAT的缺陷主要表現在以下幾方面：

(1) 不能處理嵌入式IP地址或埠

??NAT設備不能翻譯那些嵌入到應用資料部分的IP地址或埠資訊，它只能翻譯那種正常位于IP首部中的地址資訊和位于TCP/UDP首部中的埠資訊，如下圖,由于對方會使用接收到的資料包中嵌入的地址和埠進行通信，這樣就可能產生連接故障，如果通信雙方都是使用的公網IP，這不會造成什么問題，但如果那個嵌入式地址和埠是內網的，顯然連接就不可能成功，原因就如開篇所說的一樣，MSN Messenger的部分功能就使用了這種方式來傳遞IP和埠資訊，這樣就導致了NAT設備后的客戶端網路應用程式出現連接故障，

(2) 不能從公網訪問內部網路服務

??由于內網是私有IP，所以不能直接從公網訪問內部網路服務，比如WEB服務，對于這個問題，我們可以采用建立靜態映射的方法來解決，比如有一條靜態映射，是把218.70.201.185:80與192.168.0.88:80映射起的，當公網用戶要訪問內部WEB服務器時，它就首先連接到218.70.201.185:80，然后NAT設備把請求傳給192.168.0.88:80，192.168.0.88把回應回傳NAT設備，再由NAT設備傳給公網訪問用戶，

(3) 收發埠不同：有一些應用程式雖然是用A埠發送資料的，但卻要用B埠進行接收，不過NAT設備翻譯時卻不知道這一點，它仍然建立一條針對A埠的映射，結果對方回應的資料要傳給B埠時，NAT設備卻找不到相關映射條目而會丟棄資料包，

(4) 一些P2P應用在NAT后無法進行
??對于那些沒有中間服務器的純P2P應用（如電視會議，娛樂等）來說，如果大家都位于NAT設備之后，雙方是無法建立連接的，因為沒有中間服務器的中轉，NAT設備后的P2P程式在NAT設備上是不會有映射條目的，也就是說對方是不能向你發起一個連接的，現在已經有一種叫做P2P NAT穿越的技術來解決這個問題，

??NAT技術無可否認是在ipv4地址資源的短缺時候起到了緩解作用；在減少用戶申請ISP服務的花費和提供比較完善的負載平衡功能等方面帶來了不少好處，但是在ipv4地址在以后幾年將會枯竭，NAT技術不能改變ip地址空間不足的本質，然而在安全機制上也潛在著威脅，在配置和管理上也是一個挑戰，如果要從根本上解決ip地址資源的問題，ipv6才是最根本之路，在ipv4轉換到ipv6的程序中，NAT技術確實是一個不錯的選擇，相對其他的方案優勢也非常明顯，

DNS 服務器與提供內容的服務器的區別

DNS：域名系統（服務）協議

??域名系統（服務）協議（DNS）是一種分布式網路目錄服務，主要用于域名與 IP 地址的相互轉換，以及控制因特網的電子郵件的發送，大多數因特網服務依賴于 DNS 而作業，一旦 DNS 出錯，就無法連接 Web 站點，電子郵件的發送也會中止，DNS服務主要在廣域網中使用，

Web服務器
??Web服務器可以決議(handles)HTTP協議，當Web服務器接收到一個HTTP請求(request)，會回傳一個HTTP回應(response)，例如送回一個HTML頁面，為了處理一個請求(request)，Web服務器可以回應(response)一個靜態頁面或圖片，進行頁面跳轉(redirect)，或者把動態回應(dynamic response)的產生委托(delegate)給一些其它的程式例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，服務器端(server-side)JavaScript，或者一些其它的服務器端(server-side)技術，無論它們(譯者注：腳本)的目的如何，這些服務器端(server-side)的程式通常產生一個HTML的回應(response)來讓瀏覽器可以瀏覽，

DNS 劫持原理和實作

??DNS劫持的原理為：攻擊者冒充網關，把受害機的流量欺騙過來，然后充當DNS服務器，由攻擊者自己決議域名，這樣子就可以隨意的決議域名，到達劫持的目的，即dns系統被入侵或人為的修改某些記錄,如A記錄,用專業的術語來講就是通過某些手段取得某域名的決議記錄控制權，進而修改此域名的決議結果，導致對該域名的訪問由原IP地址轉入到修改后的指定IP，其結果就是對特定的網址不能訪問或訪問的是假網址，

??DNS污染：現行標準中 DNS 查詢通常使用 UDP 協議并且沒有任何驗證機制，并且根據慣例查詢者會接受第一個回傳的結果而拋棄之后的，因此只需監控 53 埠（DNS 標準埠）的 UDP查詢資料報并分析，一旦發現敏感查詢，則搶先向查詢者回傳一個偽造的錯誤結果，從而實作 DNS 污染，
DNS污染并無法阻止正確的DNS決議結果回傳，但由于旁路產生的資料包發回的速度較國外DNS服務器發回的快，作業系統認為第一個收到的資料包就是回傳結果，從而忽略其后收到的資料包，從而使得DNS污染得逞，

??應對DNS劫持最好的辦法就是手動指定DNS服務器地址，可以手動配置電腦上的DNS服務器地址，DNS服務器的地址可以咨詢你的寬帶運營商，或者使用免費的DNS服務器，國內的114.114.114.114，谷歌提供的8.8.8.8，當然也可以在寬帶路由器上配置DHCP服務器，在DHCP服務器中指定好DNS服務器地址，連接該路由器的所有設備都將使用該指定的DNS服務器地址，

對稱加密和非對稱的區別，非對稱加密有哪些

參考文章：對稱加密和非對稱加密的區別

• 對稱加密: 加密和解密的秘鑰使用的是同一個.
• 非對稱加密: 與對稱加密演算法不同，非對稱加密演算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey），

對稱加密演算法：密鑰較短，破譯困難，除了資料加密標準（DES），另一個對稱密鑰加密系統是國際資料加密演算法（IDEA），它比DES的加密性好，且對計算機性能要求也沒有那么高.

優點：演算法公開、計算量小、加密速度快、加密效率高

缺點:

??在資料傳送前，發送方和接收方必須商定好秘鑰，然后 使雙方都能保存好秘鑰，其次如果一方的秘鑰被泄露，那么加密資訊也就不安全了，另外，每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的唯一秘鑰，這會使得收、發雙方所擁有的鑰匙數量巨大，密鑰管理成為雙方的負擔，

常見的對稱加密演算法有: DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES

非對稱加密演算法：公開密鑰與私有密鑰是一對，如果用公開密鑰對資料進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對資料進行加密，那么只有用對應的公開密鑰才能解密，因為加密和解密使用的是兩個不同的密鑰，所以這種演算法叫作非對稱加密演算法，

??非對稱加密演算法實作機密資訊交換的基本程序是：甲方生成一對密鑰并將其中的一把作為公用密鑰向其它方公開；得到該公用密鑰的乙方使用該密鑰對機密資訊進行加密后再發送給甲方；甲方再用自己保存的另一把專用密鑰對加密后的資訊進行解密，甲方只能用其專用密鑰解密由其公用密鑰加密后的任何資訊，

優點：安全

缺點： 速度較慢

??常見的非對稱加密演算法有: RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）

Hash演算法（摘要演算法）
??Hash演算法特別的地方在于它是一種單向演算法，用戶可以通過hash演算法對目標資訊生成一段特定長度的唯一hash值，卻不能通過這個hash值重新獲得目標資訊，因此Hash演算法常用在不可還原的密碼存盤、資訊完整性校驗等，

常見的摘要演算法有: MD2、MD4、MD5、HAVAL、SHA
哈希演算法 能達到獲取內容的效果 所以也可以稱為摘要演算法 md5 常用來驗證檔案 就是這原理

AES 的程序

參考文章：AES 加密演算法的原理詳解
高級加密標準(AES,Advanced Encryption Standard)為最常見的對稱加密演算法(微信小程式加密傳輸就是用這個加密演算法的)，對稱加密演算法也就是加密和解密用相同的密鑰，具體的加密流程如下圖：


實際中，一般是通過RSA加密AES的密鑰，傳輸到接收方，接收方解密得到AES密鑰，然后發送方和接收方用AES密鑰來通信，

安全攻擊有哪些

安全攻擊分為哪些？
一種有用的劃分安全攻擊的方法是使用被動攻擊和主動攻擊的劃分方法，
被動攻擊
??被動攻擊的本質就是竊聽和監聽資料傳輸，攻擊者的目標是獲取傳輸的資料資訊，被動攻擊的兩種形式是訊息內容泄露攻擊和流量分析攻擊，**被動攻擊是非常難以檢測，因為它們沒有改變資料，**盡管如此，防范這些攻擊還是切實可行的，通常使用加密的方式來去實作，因此，對付被動攻擊的重點是防范而不是檢測，

(一）訊息內容泄露
??這個我們很容易理解，電話交談，電子郵件訊息和傳輸檔案中都有可能包含敏感或機密的資訊，我們需要阻止攻擊者獲取這些資訊，

（二）流量分析
??流量分析攻擊更加的巧妙，假設我們已經有一種方法可以掩蓋訊息內容或者其他資訊，確保攻擊者即使獲取資訊，他們也不能從中讀取有用的資訊，通常掩蓋資訊的方法是加密，
如果我們已經做了適當的保護，但攻擊者仍然可能觀察到這些資訊的模式，攻擊者可以得知其位置和身份，并且得到交換資訊的頻率和長度，對于猜測資訊的性質很有幫助，

主動攻擊
??主動攻擊包含改寫資料流和錯誤資料流的添加，它可以劃分為4類：假冒、重放、改寫資訊和拒絕服務，
（1）假冒
??即假冒身份，經過物體認證，得到一些權限，進行權限攻擊，
（二）重放
??重放涉及被動獲取資料單元并按照它之前的順序重新傳輸，此外來產生一個非授權的效應，
（三）改寫
??是指合法訊息的某個部分被篡改，或者訊息被延遲，被重排，從而產生非授權效應

（四）拒絕服務
??可以阻止或禁止對通信設備的正常使用和管理，這個攻擊可能有一個特殊目標：比如一個物體可能禁止把所有的訊息發送到一個特定的目的地；另一種拒絕服務的形式是對整個網路的破壞，是網路癱瘓或訊息過載從而喪失網路性能，

DDOS 有哪些，如何防范

??分布式拒絕服務(DDoS: distributed denial-of-service)攻擊是惡意破壞目標服務器、服務或網路的正常通信量的企圖，其方法是用大量Internet通信量淹沒目標或其周圍的基礎設施，DDoS攻擊通過利用多個受損的計算機系統作為攻擊流量的來源來達到有效性，被利用的機器可以包括計算機和其他網路資源，如物聯網設備，從高層來說，DDoS攻擊就像堵塞高速公路的交通堵塞，阻止常規交通到達它想要的目的地，

DDOS攻擊程序和目標

Q：DDoS攻擊是怎么作業的?

??DDoS攻擊要求攻擊者獲得對在線計算機網路的控制，以便進行攻擊，電腦或者其他機器(如物聯網設備)被惡意軟體感染，每臺電腦都變成了僵尸，然后攻擊者就可以遠程控制這群被稱為僵尸網路的機器人，

??一旦建立了僵尸網路，攻擊者就可以通過遠程控制的方法向每個機器人發送更新的指令，從而指導機器人，當僵尸網路攻擊受害者的IP地址時，每個機器人都會向目標發送請求，這可能導致目標服務器或網路溢位容量，導致對正常流量的拒絕服務，因為每個機器人都是一個合法的互聯網設備，所以很難將攻擊流量與正常流量分開，

Q：DDoS攻擊的常見型別是什么?

??不同的DDoS攻擊向量針對不同的網路連接組件，為了了解不同的DDoS攻擊是如何作業的，有必要了解網路連接是如何建立的，Internet上的網路連接由許多不同的組件或“層”組成，就像從頭開始建造房子一樣，模型中的每一步都有不同的目的，

??雖然幾乎所有的DDoS攻擊都涉及用流量淹沒目標設備或網路，但攻擊可以分為三類，攻擊者可能利用一個或多個不同的攻擊向量，或基于目標采取的對抗措施的回圈攻擊向量，

應用層攻擊（Application Layer Attacks）

攻擊目標:

??有時被稱為第7層DDoS攻擊(參照OSI模型的第7層)，這些攻擊的目標是耗盡目標的資源，攻擊針對的是在服務器上生成并回應HTTP請求交付web頁面的層，在客戶端執行一個HTTP請求很便宜，而且目標服務器回應起來也很昂貴，因為服務器通常必須加載多個檔案并運行資料庫查詢才能創建web頁面，第7層攻擊很難防御，因為流量很難標記為惡意的，

應用層攻擊實體:

HTTP Flood

??這種攻擊類似于在web瀏覽器中一次又一次地在許多不同的計算機上按下refresh——大量的HTTP請求涌向服務器，導致拒絕服務，

??這種型別的攻擊范圍從簡單到復雜，更簡單的實作可以使用相同范圍的攻擊IP地址、參考和用戶代理訪問一個URL，復雜版本可能會使用大量的攻擊IP地址，并使用隨機的參考器和用戶代理來目標隨機url，

協議攻擊（Protocol Attacks）

攻擊目標:

??協議攻擊(也稱為狀態耗盡攻擊)通過消耗web應用服務器或防火墻和負載均衡器等中間資源的所有可用狀態表容量，導致服務中斷，協議攻擊利用協議堆疊的第3層和第4層的弱點使目標無法訪問，

協議攻擊的例子:

SYN Flood

??同步洪水類似于供應室的作業人員接收來自商店前面的請求，作業人員接收到請求，然后去獲取包，并等待確認，然后再將包帶到前面，然后，作業人員在沒有確認的情況下得到更多的包請求，直到他們無法攜帶更多的包，變得不堪重負，請求開始無人應答，

??這種攻擊利用TCP握手，通過發送大量具有欺騙源IP地址的TCP“初始連接請求”SYN包給目標，目標機器回應每個連接請求，然后等待握手的最后一步，握手永遠不會發生，這會耗盡目標的資源，

容量耗盡攻擊（Volumetric Attacks）

攻擊目標:

??這類攻擊試圖通過消耗目標和大型Internet之間的所有可用帶寬來造成擁塞，通過使用一種放大形式或另一種產生大量流量的方式(如僵尸網路的請求)將大量資料發送到目標，

放大的例子:

DNS Amplification

??DNS擴增就像如果有人打電話給一家餐館，說“我要一份套餐，請給我回電話，告訴我我的全部訂單”，他們給出的回叫電話號碼就是目標顧客的號碼，只需很少的努力，就會產生長時間的回應，

??通過向具有欺騙IP地址(目標的實際IP地址)的開放DNS服務器發出請求，目標IP地址然后從服務器接收回應，攻擊者構造請求，使DNS服務器用大量資料回應目標，因此，目標接收攻擊者初始查詢的放大，

DDOS解決方案

Q：怎么才能減輕DDoS攻擊?

??減輕DDoS攻擊的關鍵問題是區分攻擊和正常通信量，例如，如果一個產品發布讓一個公司的網站擠滿了熱切的客戶，那么切斷所有的流量就是一個錯誤，如果該公司突然有一個流量激增的已知不良演員，努力減輕攻擊可能是必要的，難點在于區分真正的客戶和攻擊流量，

??在現代互聯網中，DDoS流量有多種形式，流量可以在設計上有所不同，從無欺騙的單源攻擊到復雜的自適應多矢量攻擊，多矢量DDoS攻擊使用多種攻擊路徑，以不同的方式覆寫目標，可能分散在任何一條軌跡上的緩解作業，同時攻擊協議堆疊的多個層，例如DNS放大(目標層3/4)和HTTP洪水(目標層7)是多向量DDoS的一個例子，

??減輕多矢量DDoS攻擊需要多種策略來對抗不同的軌跡，一般來說，攻擊越復雜，流量就越難以從正常的流量中分離出來——攻擊者的目標是盡可能地融入其中，使緩解的效率盡可能低，不加區別地減少或限制流量的緩解嘗試可能會將好的流量與壞的流量一起拋棄，攻擊也可能修改和適應以規避對策，為了克服破壞的復雜嘗試，分層的解決方案將帶來最大的好處，

黑洞的路由

幾乎所有網路管理員都可以使用的一種解決方案是創建一個黑洞路由，并將流量引入該路由，最簡單的形式是，當在沒有特定限制條件的情況下實作黑洞過濾時，合法的和惡意的網路流量都被路由到空路由或黑洞并從網路中洗掉，如果一個互聯網財產正在經歷DDoS攻擊，該財產的互聯網服務供應商(ISP)可能發送所有的網站流量到一個黑洞作為防御，

速度限制

限制服務器在某個時間視窗內接受的請求數量也是減輕拒絕服務攻擊的一種方法，雖然速率限制在級訓web抓取器竊取內容和減輕強制登錄嘗試方面很有用，但它本身可能不足以有效地處理復雜的DDoS攻擊，然而，在有效的DDoS緩解策略中，速率限制是一個有用的組成部分，

Web應用程式防火墻

Web應用程式防火墻(WAF)是一種可以幫助減輕第7層DDoS攻擊的工具，通過在Internet和原始服務器之間放置WAF, WAF可以充當反向代理，保護目標服務器免受某些型別的惡意通信，通過基于用于識別DDoS工具的一系列規則過濾請求，第7層的攻擊可能會受到阻礙，有效WAF的一個關鍵價值是能夠快速實作自定義規則以回應攻擊，

Anycast網路擴散

這種緩解方法使用Anycast網路將攻擊流量分散到分布式服務器網路上，直到網路吸收流量為止，就像將湍急的河流引導到單獨的較小的通道上一樣，這種方法將分布式攻擊流量的影響分散到可以管理的地方，分散了任何破壞能力，Anycast網路減輕DDoS攻擊的可靠性取決于攻擊的大小以及網路的大小和效率，