• Client發(fā)起一個HTTPS的請求
• Server把事先配置好的公鑰證書返回給客戶端。
• Client驗證公鑰證書：比如是否在有效期內，證書的用途是不是匹配Client請求的站點，是不是在CRL吊銷列表里面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操作系統(tǒng)內置的Root證書或者Client內置的Root證書），如果驗證通過則繼續(xù)，不通過則顯示警告信息。
• Client使用偽隨機數(shù)生成器生成加密所使用的對稱密鑰，然后用證書的公鑰加密這個對稱密鑰，發(fā)給Server。
• Server使用自己的私鑰解密這個消息，得到對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。
• Server使用對稱密鑰加密明文內容A，發(fā)送給Client。
• Client使用對稱密鑰解密響應的密文，得到明文內容A。
• Client再次發(fā)起HTTPS的請求，使用對稱密鑰加密請求的明文內容B，然后Server使用對稱密鑰解密密文，得到明文內容B。

數(shù)字證書

客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

?

這就存在些問題，如何保證公鑰不被篡改和信任度？

?

所以這里就需要借助第三方權威機構 CA （數(shù)字證書認證機構），將「服務器公鑰放在數(shù)字證書」（由數(shù)字證書認證機構頒發(fā)）中，只要證書是可信的，公鑰就是可信的。

通過數(shù)字證書的方式保證服務器公鑰的身份，解決冒充的風險。

請求報文

「請求頭」

HTTP 請求報文由3部分組成(請求行+請求頭+請求體)

「常見的HTTP報文頭屬性」

• Accpet
• 告訴服務端，客戶端接收什么類型的響應
• Referer
• 表示這是請求是從哪個URL進來的,比如想在網上購物，但是不知道選擇哪家電商平臺，你就去問度娘，說哪家電商的東西便宜啊，然后一堆東西彈出在你面前，第一給就是某寶，當你從這里進入某寶的時候，這個請求報文的Referer就是：www.baidu.com
• Cache-Control
• 對緩存進行控制，如一個請求希望響應的內容在客戶端緩存一年，或不被緩可以通過這個報文頭設置
• Accept-Encoding
• 例如:Accept-Encoding:gzip, deflate(這兩種都是壓縮格式)
• 這個屬性是用來告訴服務器能接受什么編碼格式，包括字符編碼,壓縮形式(一般都是壓縮形式)
• Host
• 指定要請求的資源所在的主機和端口
• User-Agent：告訴服務器，客戶端使用的操作系統(tǒng)、瀏覽器版本和名稱
• Connection

決定當前事務（三次握手和四次揮手）完成后，是否關閉網絡連接。

• 持久連接，事務完成后不關閉網絡連接 ：Connection: keep-alive
• 非持久連接，事務完成后關閉網絡連接：Connection: close

響應報文

響應報文與請求報文一樣，由三個部分組成(響應行,響應頭,響應體)

「HTTP響應報文屬性」

• Cache-Control
• 響應輸出到客戶端后，服務端通過該屬性告訴客戶端該怎么控制響應內容的緩存
• ETag
• 表示你請求資源的版本，如果該資源發(fā)生啦變化，那么這個屬性也會跟著變
• Location
• 在重定向中或者創(chuàng)建新資源時使用
• Set-Cookie
• 服務端可以設置客戶端的cookie

TCP

TCP是一個傳輸層協(xié)議，提供可靠傳輸，支持全雙工，是一個連接導向的協(xié)議。

「雙工/單工」

在任何一個時刻，如果數(shù)據(jù)只能單向發(fā)送，就是單工。

如果在某個時刻數(shù)據(jù)可以向一個方向傳輸，也可以向另一個方向反方向傳輸，而且交替進行，叫作半雙工；半雙工需要至少 1 條線路。

如果任何時刻數(shù)據(jù)都可以雙向收發(fā)，這就是全雙工，全雙工需要大于 1 條線路。

TCP 是一個雙工協(xié)議，數(shù)據(jù)任何時候都可以雙向傳輸。

這就意味著客戶端和服務端可以平等地發(fā)送、接收信息。

「TCP協(xié)議的主要特點」

• TCP是面向連接的運輸層協(xié)議；所謂面向連接就是雙方傳輸數(shù)據(jù)之前，必須先建立一條通道，例如三次握手就是建議通道的一個過程，而四次揮手則是結束銷毀通道的一個其中過程。

• 每一條TCP連接只能有兩個端點（即兩個套接字），只能是點對點的；

• TCP提供可靠的傳輸服務。傳送的數(shù)據(jù)無差錯、不丟失、不重復、按序到達；

• TCP提供全雙工通信。允許通信雙方的應用進程在任何時候都可以發(fā)送數(shù)據(jù)，因為兩端都設有發(fā)送緩存和接受緩存；

• 面向字節(jié)流。雖然應用程序與TCP交互是一次一個大小不等的數(shù)據(jù)塊，但TCP把這些數(shù)據(jù)看成一連串無結構的字節(jié)流，它不保證接收方收到的數(shù)據(jù)塊和發(fā)送方發(fā)送的數(shù)據(jù)塊具有對應大小關系，例如，發(fā)送方應用程序交給發(fā)送方的TCP10個數(shù)據(jù)塊，接收方的TCP可能只用收到的4個數(shù)據(jù)塊字節(jié)流交付給上層的應用程序

「TCP的可靠性原理」

可靠傳輸有如下兩個特點:

1. 傳輸信道無差錯,保證傳輸數(shù)據(jù)正確;
2. 不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來得及處理收到的數(shù)據(jù);

首先，采用三次握手來建立TCP連接，四次握手來釋放TCP連接，從而保證建立的傳輸信道是可靠的。

其次，TCP采用了連續(xù)ARQ協(xié)議（回退N(Go-back-N)；超時自動重傳）來保證數(shù)據(jù)傳輸?shù)恼_性，使用滑動窗口協(xié)議來保證接方能夠及時處理所接收到的數(shù)據(jù)，進行流量控制。

最后，TCP使用慢開始、擁塞避免、快重傳和快恢復來進行擁塞控制，避免網絡擁塞。

報文段

TCP雖面向字節(jié)流，但傳送的數(shù)據(jù)單元為報文段

報文段 = 首部 + 數(shù)據(jù)2部分

TCP的全部功能體現(xiàn)在它首部中各字段的作用

?

1. 首部前20個字符固定、后面有4n個字節(jié)是根據(jù)需而增加的選項
2. 故 TCP首部最小長度 = 20字節(jié)

?

「端口」：

源端口號和目地端口各占16位兩個字節(jié)，也就是端口的范圍是2^16=65535

另外1024以下是系統(tǒng)保留的，從1024-65535是用戶使用的端口范圍

「seq序號」：占4字節(jié)，TCP連接中傳送的字節(jié)流中的每個字節(jié)都按順序編號。

例如：一段報文的序號字段值是107，攜帶的數(shù)據(jù)是100個字段，下一個報文段序號從107+100=207開始。

「ack確認號」：4個字節(jié)，是期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。

例如：B收到A發(fā)送的報文，其序號字段是301，數(shù)據(jù)長度是200字節(jié)，表明B正確收到A發(fā)送的到序號500為止的數(shù)據(jù)（301+200-1=500），B期望收到A下一個數(shù)據(jù)序號是501，B發(fā)送給A的確認報文段中把ack確認號置為501。

「數(shù)據(jù)偏移」：頭部有可選字段，長度不固定，指出TCP報文段的數(shù)據(jù)起始處距離報文段的起始處有多遠。

「保留」：保留今后使用的，被標為1。

「控制位」：由8個標志位組成。每個標志位表示一個控制功能。

其中主要的6個：

• 「URG緊急指針標志」，為1表示緊急指針有效，為0忽略緊急指針。

• 「ACK確認序號標志」，為1表示確認號有效，為0表示報文不含確認信息，忽略確認號字段，上面的確認號是否有效就是通過該標識控制的。

• 「PSH標志」，為1表示帶有push標志的數(shù)據(jù)，指示接收方在接收到該報文段以后，應盡快將該報文段交給應用程序，而不是在緩沖區(qū)排隊。

• 「RST重置連接標志」，重置因為主機崩潰或其他原因而出現(xiàn)錯誤的連接，或用于拒絕非法的報文段或非法的連接。

• 「SYN同步序號」，同步序號，用于建立連接過程，在連接請求中，SYN=1和ACK=0表示該數(shù)據(jù)段沒有使用捎帶的確認域，而連接應答捎帶一個確認，即SYN=1和ACK=1。。

• 「FIN終止標志」，用于釋放連接，為1時表示發(fā)送方沒有發(fā)送了。

「窗口」：滑動窗口大小，用來告知發(fā)送端接收端緩存大小，以此控制發(fā)送端發(fā)送數(shù)據(jù)的速率，從而達到流量控制。

「校驗和」：奇偶校驗，此校驗和是對整個的TCP報文段（包括TCP頭部和TCP數(shù)據(jù)），以16位進行計算所得，由發(fā)送端計算和存儲，接收端進行驗證。

「緊急指針」：只有控制位中的URG為1時才有效，指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)。

「選項」：其長度可變，定義其他的可選參數(shù)。

粘包與拆包

TCP是面向字節(jié)流的協(xié)議，把上層應用層的數(shù)據(jù)看成字節(jié)流，所以它發(fā)送的不是固定大小的數(shù)據(jù)包，TCP協(xié)議也沒有字段說明發(fā)送數(shù)據(jù)包的大小。

而且TCP不保證接受方應用程序收到的數(shù)據(jù)塊和發(fā)送應用程序發(fā)送的數(shù)據(jù)塊具有對應的大小關系

比如發(fā)送方應用程序交給發(fā)送方TCP 10個數(shù)據(jù)塊，接受方TCP可能只用了4個數(shù)據(jù)塊就完整的把接受到的字節(jié)流交給了上層應用程序。

TCP底層并不了解上層業(yè)務數(shù)據(jù)的具體含義，它會根據(jù)TCP緩沖區(qū)的實際情況進行包的劃分，所以在業(yè)務上認為，一個完整的包可能會被TCP拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題

「TCP粘包/拆包解決策略」

由于TCP無法理解上一層的業(yè)務數(shù)據(jù)特點，所以TCP是無法保證發(fā)送的數(shù)據(jù)包不發(fā)生粘包和拆包，這個問題只能通過上層的協(xié)議棧設計來解決，解決思路有一下幾種：

• 消息定長：每個發(fā)送的數(shù)據(jù)包大小固定，比如100字節(jié)，不足100字節(jié)的用空格補充，接受方取數(shù)據(jù)的時候根據(jù)這個長度來讀取數(shù)據(jù)

• 消息末尾增加換行符來表示一條完整的消息：接收方讀取的時候根據(jù)換行符來判斷是否是一條完整的消息，如果消息的內容也包含換行符，那么這種方式就不合適了。

• 將消息分為消息頭和消息尾兩部分，消息頭指定數(shù)據(jù)長度，根據(jù)消息長度來讀取完整的消息，例如UDP協(xié)議是這么設計的，用兩個字節(jié)來表示消息長度，所以UDP不存在粘包和拆包問題。

三次握手

「第一次握手」：

客戶端將TCP報文標志位SYN置為1，隨機產生一個序號值seq=J，保存在TCP首部的序列號字段里，指明客戶端打算連接的服務器的端口，并將該數(shù)據(jù)包發(fā)送給服務器端，發(fā)送完畢后，客戶端進入SYN_SENT狀態(tài)，等待服務器端確認。

「第二次握手」：

服務器端收到數(shù)據(jù)包后由標志位SYN=1知道客戶端請求建立連接，服務器端將TCP報文標志位SYN和ACK都置為1，ack=J+1，隨機產生一個序號值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態(tài)。

「第三次握手」：

客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸數(shù)據(jù)了。

「上面寫的ack和ACK，不是同一個概念：」

• 小寫的ack代表的是頭部的確認號Acknowledge number， 縮寫ack，是對上一個包的序號進行確認的號，ack=seq+1。

• 大寫的ACK，則是我們上面說的TCP首部的標志位，用于標志的TCP包是否對上一個包進行了確認操作，如果確認了，則把ACK標志位設置成1。

「TCP為什么三次握手而不是兩次握手」

• 為了實現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護一個序列號， 以標識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經被對方收到的。三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經收到了序列號起始值的必經步驟

• 如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認

「《計算機網絡》中是這樣說的：」

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

?

在書中同時舉了一個例子，如下：

?

假如client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server，本來這是一個早已失效的報文段，但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。

于是就向client發(fā)出確認報文段，同意建立連接，假設不采用「三次握手」，那么只要server發(fā)出確認，新的連接就建立了，由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。

但server卻以為新的連接已經建立，并一直等待client發(fā)來數(shù)據(jù)，這樣，server的很多資源就白白浪費掉了。

采用「三次握手」的辦法可以防止上述現(xiàn)象發(fā)生，例如剛才那種情況，client不會向server的確認發(fā)出確認，server由于收不到確認，就知道client并沒有要求建立連接。

「什么是半連接隊列」

服務器第一次收到客戶端的 SYN 之后，就會處于 SYN_RCVD狀態(tài)，此時雙方還沒有完全建立其連接，服務器會把此種狀態(tài)下請求連接放在一個隊列里，我們把這種隊列稱之為「半連接隊列」。

當然還有一個「全連接隊列」，就是已經完成三次握手，建立起連接的就會放在全連接隊列中。如果隊列滿了就有可能會出現(xiàn)丟包現(xiàn)象。

補充一點關于「SYN-ACK 重傳次數(shù)」的問題：

服務器發(fā)送完SYN－ACK包，如果未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數(shù)超過系統(tǒng)規(guī)定的最大重傳次數(shù)，系統(tǒng)將該連接信息從半連接隊列中刪除。

「三次握手過程中可以攜帶數(shù)據(jù)嗎」

其實第三次握手的時候，是可以攜帶數(shù)據(jù)的，也就是說，第一次、第二次握手不可以攜帶數(shù)據(jù)，而第三次握手是可以攜帶數(shù)據(jù)的。

假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù)，因為攻擊者根本就不理服務器的接收、發(fā)送能力是否正常，然后瘋狂著重復發(fā) SYN 報文的話，這會讓服務器花費很多時間、內存空間來接收這些報文。也就是說，第一次握手可以放數(shù)據(jù)的話，其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。

而對于第三次的話，此時客戶端已經處于 established 狀態(tài)，也就是說，對于客戶端來說，他已經建立起連接了，并且也已經知道服務器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)沒啥毛病。

四次揮手

揮手請求可以是Client端，也可以是Server端發(fā)起的，我們假設是Client端發(fā)起：

• 第一次揮手：Client端發(fā)起揮手請求，向Server端發(fā)送標志位是FIN報文段，設置序列號seq，此時，Client端進入FIN_WAIT_1狀態(tài)，這表示Client端沒有數(shù)據(jù)要發(fā)送給Server端了。

• 第二次揮手：Server端收到了Client端發(fā)送的FIN報文段，向Client端返回一個標志位是ACK的報文段，ack設為seq加1，Client端進入FIN_WAIT_2狀態(tài)，Server端告訴Client端，我確認并同意你的關閉請求。

• 第三次揮手：Server端向Client端發(fā)送標志位是FIN的報文段，請求關閉連接，同時Client端進入LAST_ACK狀態(tài)。

• 第四次揮手 ：Client端收到Server端發(fā)送的FIN報文段，向Server端發(fā)送標志位是ACK的報文段，然后Client端進入TIME_WAIT狀態(tài)，Server端收到Client端的ACK報文段以后，就關閉連接，此時，Client端等待2MSL的時間后依然沒有收到回復，則證明Server端已正常關閉，那好，Client端也可以關閉連接了。

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

建立連接時因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。所以建立連接只需要三次握手。

由于TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議，TCP是全雙工模式。

這就意味著，關閉連接時，當Client端發(fā)出FIN報文段時，只是表示Client端告訴Server端數(shù)據(jù)已經發(fā)送完畢了。當Server端收到FIN報文并返回ACK報文段，表示它已經知道Client端沒有數(shù)據(jù)發(fā)送了，但是Server端還是可以發(fā)送數(shù)據(jù)到Client端的，所以Server很可能并不會立即關閉SOCKET，直到Server端把數(shù)據(jù)也發(fā)送完畢。

當Server端也發(fā)送了FIN報文段時，這個時候就表示Server端也沒有數(shù)據(jù)要發(fā)送了，就會告訴Client端，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會愉快的中斷這次TCP連接。

「為什么TIME_WAIT要等待2MSL？」

MSL：報文段最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間。

有以下兩個原因：

• 第一點：保證TCP協(xié)議的全雙工連接能夠可靠關閉：由于IP協(xié)議的不可靠性或者是其它網絡原因，導致了Server端沒有收到Client端的ACK報文，那么Server端就會在超時之后重新發(fā)送FIN，如果此時Client端的連接已經關閉處于CLOESD狀態(tài)，那么重發(fā)的FIN就找不到對應的連接了，從而導致連接錯亂，所以，Client端發(fā)送完最后的ACK不能直接進入CLOSED狀態(tài)，而要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最后正確關閉連接。
• 第二點：保證這次連接的重復數(shù)據(jù)段從網絡中消失 如果Client端發(fā)送最后的ACK直接進入CLOSED狀態(tài)，然后又再向Server端發(fā)起一個新連接，這時不能保證新連接的與剛關閉的連接的端口號是不同的，也就是新連接和老連接的端口號可能一樣了，那么就可能出現(xiàn)問題：如果前一次的連接某些數(shù)據(jù)滯留在網絡中，這些延遲數(shù)據(jù)在建立新連接后到達Client端，由于新老連接的端口號和IP都一樣，TCP協(xié)議就認為延遲數(shù)據(jù)是屬于新連接的，新連接就會接收到臟數(shù)據(jù)，這樣就會導致數(shù)據(jù)包混亂，所以TCP連接需要在TIME_WAIT狀態(tài)等待2倍MSL，才能保證本次連接的所有數(shù)據(jù)在網絡中消失。

流量控制

「RTT和RTO」

RTT：發(fā)送一個數(shù)據(jù)包到收到對應的ACK，所花費的時間

RTO：重傳時間間隔（TCP在發(fā)送一個數(shù)據(jù)包后會啟動一個重傳定時器，RTO即定時器的重傳時間）

開始預先算一個定時器時間，如果回復ACK，重傳定時器就自動失效，即不需要重傳；如果沒有回復ACK，RTO定時器時間就到了，重傳。

RTO是本次發(fā)送當前數(shù)據(jù)包所預估的超時時間，RTO不是固定寫死的配置，是經過RTT計算出來的。

「滑動窗口」

TCP的滑動窗口主要有兩個作用：

1. 保證TCP的可靠性

2. 保證TCP的流控特性

TCP報文頭有個字段叫Window，用于接收方通知發(fā)送方自己還有多少緩存區(qū)可以接收數(shù)據(jù)，發(fā)送方根據(jù)接收方的處理能力來發(fā)送數(shù)據(jù)，不會導致接收方處理不過來，這便是流量控制。

發(fā)送方都維持了一個連續(xù)的允許發(fā)送的幀的序號，稱為發(fā)送窗口；同時，接收方也維持了一個連續(xù)的允許接收的幀的序號，稱為接收窗口。

發(fā)送窗口和接收窗口的序號的上下界不一定要一樣，甚至大小也可以不同。

不同的滑動窗口協(xié)議窗口大小一般不同。

發(fā)送方窗口內的序列號代表了那些已經被發(fā)送，但是還沒有被確認的幀，或者是那些可以被發(fā)送的幀

滑動窗口由四部分組成每個字節(jié)的數(shù)據(jù)都有唯一順序的編碼，隨著時間發(fā)展，未確認部分與可以發(fā)送數(shù)據(jù)包編碼部分向右移動，形式滑動窗口

1. 綠色：發(fā)送成功并已經ACK確認的數(shù)據(jù)
2. 黃色：發(fā)送成功等待ACK確認的數(shù)據(jù)(占用滑動窗口大小)
3. 紫色：滑動窗口剩余大小可以發(fā)送的字節(jié)數(shù)量(滑動窗口可用大小)
4. 灰色：后續(xù)數(shù)據(jù)編碼

接收窗口的大小就是滑動窗口的最大值，數(shù)據(jù)傳輸過程中滑動窗口的可用大小是動態(tài)變化的。

但是還有這么一點，滑動窗口的設計僅僅是考慮到了處理方的處理能力，但是沒有考慮到道路的通暢問題

就好像服務端可以處理100M數(shù)據(jù)，但是傳輸?shù)臄?shù)據(jù)99M都堵在路上了，這不就是導致道路阻塞了么？這就需要另外一個設計「擁塞避免」

「流量控制的目的」

如果發(fā)送者發(fā)送數(shù)據(jù)過快，接收者來不及接收，那么就會有分組丟失。

為了避免分組丟失，控制發(fā)送者的發(fā)送速度，使得接收者來得及接收，這就是流量控制。

流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。

「如何實現(xiàn)流量控制」

由滑動窗口協(xié)議（連續(xù)ARQ協(xié)議）實現(xiàn)?；瑒哟翱趨f(xié)議既保證了分組無差錯、有序接收，也實現(xiàn)了流量控制。

主要的方式就是接收方返回的 ACK 中會包含自己的接收窗口的大小，并且利用大小來控制發(fā)送方的數(shù)據(jù)發(fā)送。

「流量控制引發(fā)的死鎖」

當發(fā)送者收到了一個窗口為0的應答，發(fā)送者便停止發(fā)送，等待接收者的下一個應答。

但是如果這個窗口不為0的應答在傳輸過程丟失，發(fā)送者一直等待下去，而接收者以為發(fā)送者已經收到該應答，等待接收新數(shù)據(jù)，這樣雙方就相互等待，從而產生死鎖。

為了避免流量控制引發(fā)的死鎖，TCP使用了「持續(xù)計時器」。每當發(fā)送者收到一個零窗口的應答后就啟動該計時器。時間一到便主動發(fā)送報文詢問接收者的窗口大小。若接收者仍然返回零窗口，則重置該計時器繼續(xù)等待；若窗口不為0，則表示應答報文丟失了，此時重置發(fā)送窗口后開始發(fā)送，這樣就避免了死鎖的產生。

擁塞控制

「為什么要進行擁塞控制」

假設網絡已經出現(xiàn)擁塞，如果不處理擁塞，那么延時增加，出現(xiàn)更多丟包，觸發(fā)發(fā)送方重傳數(shù)據(jù)，加劇擁塞情況，繼續(xù)惡性循環(huán)直至網絡癱瘓。

擁塞控制與流量控制的適應場景和目的均不同。

擁塞發(fā)生前，可避免流量過快增長拖垮網絡；擁塞發(fā)生時，唯一的選擇就是降低流量。

主要使用4種算法完成擁塞控制：

1. 慢啟動
2. 擁塞避免
3. 快重傳算法
4. 快速恢復算法

算法1、2適用于擁塞發(fā)生前，算法3適用于擁塞發(fā)生時，算法4適用于擁塞解決后（相當于擁塞發(fā)生前）。

「rwnd與cwnd」

rwnd（Receiver Window，接收者窗口）與cwnd（Congestion Window，擁塞窗口）：

• rwnd是用于流量控制的窗口大小，主要取決于接收方的處理速度，由接收方通知發(fā)送方被動調整。

• cwnd是用于擁塞處理的窗口大小，取決于網絡狀況，由發(fā)送方探查網絡主動調整。

同時考慮流量控制與擁塞處理，則發(fā)送方窗口的大小不超過min{rwnd, cwnd}。

「慢啟動算法」

慢開始算法的思路就是，不要一開始就發(fā)送大量的數(shù)據(jù)，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。

這里用報文段的個數(shù)作為擁塞窗口的大小舉例說明慢開始算法，實際的擁塞窗口大小是以字節(jié)為單位的。

一個傳輸輪次所經歷的時間其實就是往返時間RTT，而且每經過一個傳輸輪次，擁塞窗口cwnd就加倍。

為了防止cwnd增長過大引起網絡擁塞，還需設置一個慢開始門限ssthresh狀態(tài)變量。

?

ssthresh的用法如下：

?

• cwnd<ssthresh時，使用慢開始算法。

• 當cwnd>ssthresh時，改用擁塞避免算法。

• 當cwnd=ssthresh時，慢開始與擁塞避免算法任意

注意，這里的慢并不是指cwnd的增長速率慢，而是指在TCP開始發(fā)送報文段時先設置cwnd=1，然后逐漸增大，這當然比按照大的cwnd一下子把許多報文段突然注入到網絡中要慢得多。

「擁塞避免算法」

讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。

這樣擁塞窗口cwnd按線性規(guī)律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多

無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網絡出現(xiàn)擁塞（其根據(jù)就是沒有按時收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為無法判定，所以都當做擁塞來處理），就把慢開始門限ssthresh設置為出現(xiàn)擁塞時的發(fā)送窗口大小的一半（但不能小于2）。

然后把擁塞窗口cwnd重新設置為1，執(zhí)行慢開始算法。

這樣做的目的就是要迅速減少主機發(fā)送到網絡中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

「整個擁塞控制的流程：」

假定cwnd=24時，網絡出現(xiàn)超時（擁塞），則更新后的ssthresh=12，cwnd重新設置為1，并執(zhí)行慢開始算法。

當cwnd=12=ssthresh時，改為執(zhí)行擁塞避免算法

注意：擁塞避免并非完全能夠避免了阻塞，而是使網絡比較不容易出現(xiàn)擁塞。

「快重傳算法」

快重傳要求接收方在收到一個失序的報文段后就立即發(fā)出重復確認（為的是使發(fā)送方及早知道有報文段沒有到達對方，可提高網絡吞吐量約20%）而不要等到自己發(fā)送數(shù)據(jù)時捎帶確認。

快重傳算法規(guī)定，發(fā)送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待設置的重傳計時器時間到期

「快恢復算法」

快重傳配合使用的還有快恢復算法，有以下兩個要點：

• 當發(fā)送方連續(xù)收到三個重復確認時，就把ssthresh門限減半（為了預防網絡發(fā)生擁塞）。

• 但是接下去并不執(zhí)行慢開始算法

考慮到如果網絡出現(xiàn)擁塞的話就不會收到好幾個重復的確認，所以發(fā)送方現(xiàn)在認為網絡可能沒有出現(xiàn)擁塞。

所以此時不執(zhí)行慢開始算法，而是將cwnd設置為ssthresh減半后的值，然后執(zhí)行擁塞避免算法，使cwnd緩慢增大。

Socket

即套接字，是應用層 與 TCP/IP 協(xié)議族通信的中間軟件抽象層，表現(xiàn)為一個封裝了 TCP / IP協(xié)議族 的編程接口（API）

Socket不是一種協(xié)議，而是一個編程調用接口（API），屬于傳輸層（主要解決數(shù)據(jù)如何在網絡中傳輸）

對用戶來說，只需調用Socket去組織數(shù)據(jù)，以符合指定的協(xié)議，即可通信

UDP

「UDP協(xié)議特點」

• UDP是無連接的傳輸層協(xié)議；

• UDP使用盡最大努力交付，不保證可靠交付；

• UDP是面向報文的，對應用層交下來的報文，不合并，不拆分，保留原報文的邊界；

• UDP沒有擁塞控制，因此即使網絡出現(xiàn)擁塞也不會降低發(fā)送速率；

• UDP支持一對一　一對多　多對多的交互通信；

• UDP的首部開銷小，只有８字節(jié)

「TCP和UDP的區(qū)別」

• TCP是可靠傳輸，UDP是不可靠傳輸;

• TCP面向連接，UDP無連接;

• TCP傳輸數(shù)據(jù)有序，UDP不保證數(shù)據(jù)的有序性;

• TCP不保存數(shù)據(jù)邊界，UDP保留數(shù)據(jù)邊界;

• TCP傳輸速度相對UDP較慢;

• TCP有流量控制和擁塞控制，UDP沒有;

• TCP是重量級協(xié)議，UDP是輕量級協(xié)議;

• TCP首部較長20字節(jié)，UDP首部較短８字節(jié);

「基于TCP和UDP的常用協(xié)議」

HTTP、HTTPS、FTP、TELNET、SMTP(簡單郵件傳輸協(xié)議)協(xié)議基于可靠的TCP協(xié)議。

TFTP、DNS、DHCP、TFTP、SNMP(簡單網絡管理協(xié)議)、RIP基于不可靠的UDP協(xié)議

報文段

UDP的報文段共有2個字段：數(shù)據(jù)字段 + 首部字段

「UDP報文中每個字段的含義如下：」

• 源端口：這個字段占據(jù) UDP 報文頭的前 16 位，通常包含發(fā)送數(shù)據(jù)報的應用程序所使用的 UDP 端口，接收端的應用程序利用這個字段的值作為發(fā)送響應的目的地址，這個字段是可選的，所以發(fā)送端的應用程序不一定會把自己的端口號寫入該字段中，如果不寫入端口號，則把這個字段設置為 0，這樣，接收端的應用程序就不能發(fā)送響應了。
• 目的端口：接收端計算機上 UDP 軟件使用的端口，占據(jù) 16 位。
• 長度：該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報長度，包含 UDP 報文頭和 UDP 數(shù)據(jù)長度，因為 UDP 報文頭長度是 8 個字節(jié)，所以這個值最小為 8。
• 校驗值：該字段占據(jù) 16 位，可以檢驗數(shù)據(jù)在傳輸過程中是否被損壞。

網絡層

MAC地址

MAC稱為物理地址，也叫硬件地址，用來定義網絡設備的位置，MAC地址是網卡出廠時設定的，是固定的（但可以通過在設備管理器中或注冊表等方式修改，同一網段內的MAC地址必須唯一）。

MAC地址采用十六進制數(shù)表示，長度是6個字節(jié)（48位），分為前24位和后24位。

?

MAC地址對應于OSI參考模型的第二層數(shù)據(jù)鏈路層，工作在數(shù)據(jù)鏈路層的交換機維護著計算機MAC地址和自身端口的數(shù)據(jù)庫，交換機根據(jù)收到的數(shù)據(jù)幀中的目的MAC地址字段來轉發(fā)數(shù)據(jù)幀。

?

IP地址

常見的IP地址分為IPv4與IPv6兩大類，當前廣泛應用的是IPv4，目前IPv4幾乎耗盡，下一階段必然會進行版本升級到IPv6；

IP地址是以網絡號和主機號來標示網絡上的主機的，我們把網絡號相同的主機稱之為本地網絡，網絡號不相同的主機稱之為遠程網絡主機

本地網絡中的主機可以直接相互通信；遠程網絡中的主機要相互通信必須通過本地網關（Gateway）來傳遞轉發(fā)數(shù)據(jù)。

IP地址對應于OSI參考模型的第三層網絡層，工作在網絡層的路由器根據(jù)目標IP和源IP來判斷是否屬于同一網段，如果是不同網段，則轉發(fā)數(shù)據(jù)包。

「IP地址格式和表示」

IP地址(IPv4)由32位二進制數(shù)組成，分為4段（4個字節(jié)），每一段為8位二進制數(shù)（1個字節(jié)）

每一段8位二進制，中間使用英文的標點符號.隔開

由于二進制數(shù)太長，為了便于記憶和識別，把每一段8位二進制數(shù)轉成十進制，大小為0至255。

IP地址的這種表示法叫做「點分十進制表示法」。

IP地址表示為：xxx.xxx.xxx.xxx

舉個栗子：210.21.196.6就是一個IP地址的表示。

計算機的IP地址由兩部分組成，一部分為網絡標識，一部分為主機標識，同一網段內的計算機網絡部分相同，主機部分不能同時重復出現(xiàn)。

「路由器」連接不同網段，負責不同網段之間的數(shù)據(jù)轉發(fā)，「交換機」連接的是同一網段的計算機。

通過設置網絡地址和主機地址，在互相連接的整個網絡中保證每臺主機的IP地址不會互相重疊，即IP地址具有了唯一性。

「IP地址分類詳解」

IP地址分A、B、C、D、E五類，其中A、B、C這三類是比較常用的IP地址，D、E類為特殊地址。

子網掩碼

「子網掩碼的概念及作用」

通過子網掩碼，才能表明一臺主機所在的子網與其他子網的關系，使網絡正常工作。

子網掩碼和IP地址做與運算，分離出IP地址中的網絡地址和主機地址，用于判斷該IP地址是在本地網絡上，還是在遠程網絡網上。

子網掩碼還用于將網絡進一步劃分為若干子網，以避免主機過多而擁堵或過少而IP浪費。

「子網掩碼的組成」

同IP地址一樣，子網掩碼是由長度為32位二進制數(shù)組成的一個地址。

子網掩碼32位與IP地址32位相對應，IP地址如果某位是網絡地址，則子網掩碼為1，否則為0。

舉個栗子：如：11111111.11111111.11111111.00000000

?

左邊連續(xù)的1的個數(shù)代表網絡號的長度，（使用時必須是連續(xù)的，理論上也可以不連續(xù)），右邊連續(xù)的0的個數(shù)代表主機號的長度。

?

「為什么要使用子網掩碼」

兩臺主機要通信，首先要判斷是否處于同一網段，即網絡地址是否相同。

如果相同，那么可以把數(shù)據(jù)包直接發(fā)送到目標主機，否則就需要路由網關將數(shù)據(jù)包轉發(fā)送到目的地。

?

可以這么簡單的理解：A主機要與B主機通信，A和B各自的IP地址與A主機的子網掩碼進行And與運算，看得出的結果：

1、結果如果相同，則說明這兩臺主機是處于同一個網段，這樣A可以通過ARP廣播發(fā)現(xiàn)B的MAC地址，B也可以發(fā)現(xiàn)A的MAC地址來實現(xiàn)正常通信。

2、如果結果不同，ARP廣播會在本地網關終結，這時候A會把發(fā)給B的數(shù)據(jù)包先發(fā)給本地網關，網關再根據(jù)B主機的IP地址來查詢路由表，再將數(shù)據(jù)包繼續(xù)傳遞轉發(fā)，最終送達到目的地B。

?

?

計算機的網關（Gateway）就是到其他網段的出口，也就是路由器接口IP地址。

路由器接口使用的IP地址可以是本網段中任何一個地址，不過通常使用該網段的第一個可用的地址或最后一個可用的地址，這是為了盡可能避免和本網段中的主機地址沖突。

?

在如下拓撲圖示例中，A與B，C與D，都可以直接相互通信（都是屬于各自同一網段，不用經過路由器）

但是A與C，A與D，B與C，B與D它們之間不屬于同一網段，所以它們通信是要經過本地網關，然后路由器根據(jù)對方IP地址，在路由表中查找恰好有匹配到對方IP地址的直連路由，于是從另一邊網關接口轉發(fā)出去實現(xiàn)互連

「子網掩碼和IP地址的關系」

子網掩碼是用來判斷任意兩臺主機的IP地址是否屬于同一網絡的依據(jù)

拿雙方主機的IP地址和自己主機的子網掩碼做與運算，如結果為同一網絡，就可以直接通信

「如何根據(jù)IP地址和子網掩碼，計算網絡地址：」

將IP地址與子網掩碼轉換成二進制數(shù)。

將二進制形式的 IP 地址與子網掩碼做與運算。

將得出的結果轉化為十進制，便得到網絡地址。

網關

網關實質上是一個網絡通向其他網絡的IP地址。

比如有網絡A和網絡B，網絡A的IP地址范圍為192.168.1.1~192. 168.1.254，子網掩碼為255.255.255.0；

網絡B的IP地址范圍為192.168.2.1~192.168.2.254，子網掩碼為255.255.255.0。

在沒有路由器的情況下，兩個網絡之間是不能進行TCP/IP通信的，即使是兩個網絡連接在同一臺交換機(或集線器)上，TCP/IP協(xié)議也會根據(jù)子網掩碼(255.255.255.0)判定兩個網絡中的主機處在不同的網絡里。

而要實現(xiàn)這兩個網絡之間的通信，則必須通過網關。

如果網絡A中的主機發(fā)現(xiàn)數(shù)據(jù)包的目的主機不在本地網絡中，就把數(shù)據(jù)包轉發(fā)給它自己的網關，再由網關轉發(fā)給網絡B的網關，網絡B的網關再轉發(fā)給網絡B的某個主機。網絡B向網絡A轉發(fā)數(shù)據(jù)包的過程。

「所以說，只有設置好網關的IP地址，TCP/IP協(xié)議才能實現(xiàn)不同網絡之間的相互通信?！?/strong>

?

那么這個IP地址是哪臺機器的IP地址呢？

?

網關的IP地址是具有路由功能的設備的IP地址，具有路由功能的設備有路由器、啟用了路由協(xié)議的服務器(實質上相當于一臺路由器)、代理服務器(也相當于一臺路由器)。

Ping

Ping是我們測試網絡連接的常用指令。

它利用ICMP報文檢測網絡連接。

「假設A ping B」

1. ping通知系統(tǒng)建立一個固定格式的ICMP請求數(shù)據(jù)包。

2. ICMP協(xié)議打包這個數(shù)據(jù)包和B的IP地址轉交給IP協(xié)議層

3. IP層協(xié)議將機器B的IP地址為目的地址，本機的IP地址為源地址，加上一些頭部必要的控制信息，構建一個IP數(shù)據(jù)包

4. 獲取B的MAC地址，做這個操作首先機器A會判斷B是否在同一網段內，若IP層協(xié)議通過B的IP地址和自己的子網掩碼，發(fā)現(xiàn)它跟自己屬于同一網絡，就直接在本網絡查找這臺機器的MAC，否則則通過路由器進行類似查找。

?

接下來是ARP協(xié)議根據(jù)IP地址查找MAC地址的過程:

?

• 若兩臺機器之前有過通信，在機器A的ARP緩存表里應該存有B的IP與其MAC地址的映射關系。

• 若沒有，則通過發(fā)送ARP請求廣播，得到回應的B機器MAC地址，并交給數(shù)據(jù)鏈路層

1. 數(shù)據(jù)鏈路層構建一個數(shù)據(jù)幀，目的地址是IP層傳過來的MAC地址，源地址是本機的MAC地址，再附加一些必要的控制信息，依據(jù)以太網的介質訪問規(guī)則將他們傳送出去

2. 機器B收到這個數(shù)據(jù)幀后，先檢查目的地址，和本機MAC地址對比：

符合，接受，接收后檢查該數(shù)據(jù)幀，將IP數(shù)據(jù)包從幀中提取出來，交給本機的的IP地址協(xié)議層協(xié)議，IP協(xié)議層檢查之后，將有用的信息提取給ICMP協(xié)議，后者處理，馬上構建一個ICMP應答包，發(fā)送給A，其過程和主機A發(fā)送ICMP請求包到B的過程類似，但不用ARP廣播收取A的信息，因為請求包中已經有足夠的信息用于B回應A。

若不符合，丟棄。

可以知道PING的過程即一段發(fā)送報文和接受確認報文的過程，在來回直接可以計算時延。

DNS

DNS通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。

「通俗的講」，我們更習慣于記住一個網站的名字，www.baidu.com，而不是記住它的ip地址，比如：167.23.10.2

「工作原理」

將主機域名轉換為ip地址，屬于應用層協(xié)議，使用UDP傳輸。

第一步，客戶端向本地DNS服務器發(fā)送解析請求

第二步，本地DNS如有相應記錄會直接返回結果給客戶端，如沒有就向DNS根服務器發(fā)送請求

第三步,DSN根服務器接收到請求，返回給本地服務器一個所查詢域的主域名服務器的地址

第四步，本地dns服務器再向返回的主域名服務器地址發(fā)送查詢請求

第五步，主域名服務器如有記錄就返回結果，沒有的話返回相關的下級域名服務器地址

第六步，本地DNS服務器繼續(xù)向接收到的地址進行查詢請求

第七步，下級域名服務器有相應記錄，返回結果

第八步，本地dns服務器將收到的返回地址發(fā)給客戶端，同時寫入自己的緩存，以便下次查詢

DNS域名查詢實際上就是個不斷遞歸查詢的過程，直到查找到相應結果，需要注意的時，當找不到相應記錄，會返回空結果，而不是超時信息

DNS記錄

?

A記錄

?

定義www.example.com的ip地址
www.example.com.     IN     A     139.18.28.5;


上面的就是一條 DNS 記錄，純文本即可。

www.example.com 是要解析的域名。

A 是記錄的類型，A 記錄代表著這是一條用于解析 IPv4 地址的記錄。

從這條記錄可知，www.example.com的 IP 地址是 139.18.28.5。

?

CNAME

?

CNAME用于定義域名的別名，如下面這條 DNS 記錄：

定義www.example.com的別名
a.example.com.          IN     CNAME   b.example.com.

這條 DNS 記錄定義了 a.example.com 是 b.example.com 的別名。

用戶在瀏覽器中輸入 a.example.com 時候，通過 DNS 查詢會知道 a.example.com 是 b.example.com 的別名，因此需要實際 IP 的時候，會去拿 b.example.com 的 A 記錄。

當你想把一個網站遷移到新域名，舊域名仍然保留的時候；還有當你想將自己的靜態(tài)資源放到 CDN 上的時候，CNAME 就非常有用。

?

AAAA 記錄

?

A 記錄是域名和 IPv4 地址的映射關系。和 A 記錄類似，AAAA 記錄則是域名和 IPv6 地址的映射關系。

?

MX記錄

?

MX 記錄是郵件記錄，用來描述郵件服務器的域名。

在工作中，我們經常會發(fā)郵件到某個同事的郵箱。

比如說，發(fā)送一封郵件到 xiaoming@xiaoflyfish.com，那么如何知道哪個 IP 地址是郵件服務器呢？

這個時候就可以用到下面這條 MX 記錄：

IN MX mail.xiaoflyfish.com


mail.xiaoflyfish.com 的 IP 地址可以通過查詢 mail.xiaoflyfishcom的 A 記錄和 AAAA 記錄獲得。

?

NS 記錄

?

NS記錄是描述 DNS 服務器網址。從 DNS 的存儲結構上說，Name Server 中含有權威 DNS 服務的目錄。

也就是說，NS 記錄指定哪臺 Server 是回答 DNS 查詢的權威域名服務器。

當一個 DNS 查詢看到 NS 記錄的時候，會再去 NS 記錄配置的 DNS 服務器查詢，得到最終的記錄。如下面這個例子：

a.com.     IN      NS      ns1.a.com.
a.com.     IN      NS      ns2.a.com.

當解析 a.com 地址時，我們看到 a.com 有兩個 NS 記錄，所以確定最終 a.com 的記錄在 ns1.a.com 和 ns2.a.com 上。

從設計上看，ns1 和 ns2 是網站 a.com 提供的智能 DNS 服務器，可以提供負載均衡、分布式 Sharding 等服務。

比如當一個北京的用戶想要訪問 a.com 的時候，ns1 看到這是一個北京的 IP 就返回一個離北京最近的機房 IP。

上面代碼中 a.com 配置了兩個 NS 記錄。

通常 NS 不會只有一個，這是為了保證高可用，一個掛了另一個還能繼續(xù)服務。

通常數(shù)字小的 NS 記錄優(yōu)先級更高，也就是 ns1 會優(yōu)先于 ns2 響應。

配置了上面的 NS 記錄后，如果還配置了 a.com 的 A 記錄，那么這個 A 記錄會被 NS 記錄覆蓋。

ARP協(xié)議

ARP即地址解析協(xié)議， 用于實現(xiàn)從 IP 地址到 MAC 地址的映射，即詢問目標IP對應的MAC地址。

「ARP協(xié)議的工作過程」

首先，每個主機都會有自己的ARP緩存區(qū)中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關系

當源主機要發(fā)送數(shù)據(jù)時，首先檢測ARP列表中是否對應IP地址的目的主機的MAC地址，如果有，則直接發(fā)送數(shù)據(jù)，如果沒有，就向本網段的所有主機發(fā)送ARP數(shù)據(jù)包

當本網絡的所有主機收到該ARP數(shù)據(jù)包時，首先檢查數(shù)據(jù)包中的IP地址是否是自己的IP地址，如果不是，則忽略該數(shù)據(jù)包，如果是，則首先從數(shù)據(jù)包中取出源主機的IP和MAC地址寫入到ARP列表中，如果存在，則覆蓋然后將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址

源主機收到ARP響應包后，將目的主機的IP和MAC地址寫入ARP列表，并利用此信息發(fā)送數(shù)據(jù)，如果源主機一直沒有收到ARP響應數(shù)據(jù)包，表示ARP查詢失敗。

數(shù)字簽名

網絡傳輸過程中需要經過很多中間節(jié)點，雖然數(shù)據(jù)無法被解密，但可能被篡改

數(shù)字簽名校驗數(shù)據(jù)的完整性

「數(shù)字簽名有兩種功效」：

• 能確定消息確實是由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。

• 數(shù)字簽名能確定消息的完整性，證明數(shù)據(jù)是否未被篡改過。

將一段文本先用Hash函數(shù)生成消息摘要，然后用發(fā)送者的私鑰加密生成數(shù)字簽名，與原文文一起傳送給接收者

接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原文產生一個摘要信息，與上一步得到的摘要信息對比。

如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性。

SQL注入

SQL注入的原理是將SQL代碼偽裝到輸入參數(shù)中，傳遞到服務器解析并執(zhí)行的一種攻擊手法。

「SQL注入攻擊實例」

比如，在一個登錄界面，要求輸入用戶名和密碼，可以這樣輸入實現(xiàn)免賬號登錄：

用戶名： 'or 1 = 1 --
密 碼：


用戶一旦點擊登錄，如若沒有做特殊處理，那么這個非法用戶就很得意的登陸進去了。

下面我們分析一下：從理論上說，后臺認證程序中會有如下的SQL語句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” '”;

因此，當輸入了上面的用戶名和密碼，上面的SQL語句變成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’


分析上述SQL語句我們知道，username=' or 1=1 這個語句一定會成功；然后后面加兩個 -，這意味著注釋，它將后面的語句注釋，讓他們不起作用，這樣，上述語句永遠都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。

「應對方法」

?

預編譯

?

使用預編譯手段，綁定參數(shù)是最好的防SQL注入的方法。

目前許多的ORM框架及JDBC等都實現(xiàn)了SQL預編譯和參數(shù)綁定功能，攻擊者的惡意SQL會被當做SQL的參數(shù)而不是SQL命令被執(zhí)行。

在mybatis的mapper文件中，對于傳遞的參數(shù)我們一般是使用 # 和$來獲取參數(shù)值。

當使用#時，變量是占位符，就是一般我們使用java的jdbc的PrepareStatement時的占位符，所有可以防止sql注入；

當使用$時，變量就是直接追加在sql中，一般會有sql注入問題。

?

使用正則表達式過濾傳入的參數(shù)

?

?

過濾參數(shù)中含有的一些數(shù)據(jù)庫關鍵詞

?

加密算法

加密算法分「對稱加密」 和 「非對稱加密」，其中對稱加密算法的加密與解密密鑰相同，非對稱加密算法的加密密鑰與解密密鑰不同，此外，還有一類不需要密鑰的「散列算法」。

常見的 「對稱加密」 算法主要有 DES、3DES、AES 等，常見的 「非對稱算法」 主要有 RSA、DSA 等，「散列算法」 主要有 SHA-1、MD5 等。

對稱加密

在 「對稱加密算法」 中，使用的密鑰只有一個，發(fā)送和接收雙方都使用這個密鑰對數(shù)據(jù)進行 「加密」 和 「解密」。

• 數(shù)據(jù)加密過程：在對稱加密算法中，數(shù)據(jù)發(fā)送方 將 「明文」 (原始數(shù)據(jù)) 和 「加密密鑰」 一起經過特殊 「加密處理」，生成復雜的 「加密密文」 進行發(fā)送。

• 數(shù)據(jù)解密過程：「數(shù)據(jù)接收方」 收到密文后，若想讀取原數(shù)據(jù)，則需要使用 「加密使用的密鑰」 及相同算法的 「逆算法」 對加密的密文進行解密，才能使其恢復成 「可讀明文」。

非對稱加密

「非對稱加密算法」，它需要兩個密鑰，一個稱為 「公開密鑰」 (public key)，即 「公鑰」，另一個稱為 「私有密鑰」 (private key)，即 「私鑰」。

因為 「加密」 和 「解密」 使用的是兩個不同的密鑰，所以這種算法稱為 「非對稱加密算法」。

1. 如果使用 「公鑰」 對數(shù)據(jù) 「進行加密」，只有用對應的 「私鑰」 才能 「進行解密」。

2. 如果使用 「私鑰」 對數(shù)據(jù) 「進行加密」，只有用對應的 「公鑰」 才能 「進行解密」。

「例子」：甲方生成 「一對密鑰」 并將其中的一把作為 「公鑰」 向其它人公開，得到該公鑰的 「乙方」 使用該密鑰對機密信息 「進行加密」 后再發(fā)送給甲方，甲方再使用自己保存的另一把 「專用密鑰」 (「私鑰」)，對 「加密」 后的信息 「進行解密」。

網絡攻擊

CSRF和XSS

「XSS：」

跨站腳本是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。

它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響，這類攻擊通常包含了HTML以及用戶端腳本語言。

比如通過客戶端腳本語言（最常見如：JavaScript）

在一個論壇發(fā)帖中發(fā)布一段惡意的JavaScript代碼就是腳本注入，如果這個代碼內容有請求外部服務器，那么就叫做XSS

「XSS攻擊分類」

?

反射性XSS攻擊 (非持久性XSS攻擊)

?

例如，正常發(fā)送消息：

http://www./message.php?send=Hello,World！

接收者將會接收信息并顯示HelloWorld；但是，非正常發(fā)送消息：

http://www./message.php?send=<script>alert('foolish!’)</script>！


接收者接收消息顯示的時候將會彈出警告窗口！

?

持久性XSS攻擊 (留言板場景)

?

一般指XSS攻擊代碼存儲在網站數(shù)據(jù)庫，當一個頁面被用戶打開的時候執(zhí)行。

也就是說，每當用戶使用瀏覽器打開指定頁面時，腳本便執(zhí)行。

與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。

從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數(shù)據(jù)庫中，然后客戶端打開時就執(zhí)行這些攻擊代碼。

例如，留言板表單中的表單域：

<input type='text' name='content' value='這里是用戶填寫的數(shù)據(jù)'>

正常操作流程是：用戶是提交相應留言信息 — 將數(shù)據(jù)存儲到數(shù)據(jù)庫 — 其他用戶訪問留言板，應用去數(shù)據(jù)并顯示；

而非正常操作流程是攻擊者在value填寫:

<script>alert('foolish!’)；</script> <!--或者html其他標簽（破壞樣式。。。）、一段攻擊型代碼-->


并將數(shù)據(jù)提交、存儲到數(shù)據(jù)庫中；當其他用戶取出數(shù)據(jù)顯示的時候，將會執(zhí)行這些攻擊性代碼

「CSRF：」

跨站請求偽造，是一種挾制用戶在當前已登錄的Web應用程序上執(zhí)行非本意的操作的攻擊方法。

比如冒充用戶發(fā)起請求（在用戶不知情的情況下），完成一些違背用戶意愿的請求（如惡意發(fā)帖，刪帖，改密碼，發(fā)郵件等）。

DOS攻擊

DOS：中文名稱是拒絕服務，該攻擊的效果是使得計算機或網絡無法提供正常的服務

「DOS攻擊的原理：」

首先攻擊者向被攻擊的服務器發(fā)送大量的虛假IP請求，被攻擊者在收到請求后返回確認信息，等待攻擊者進行確認，該過程需要TCP的三次握手，由于攻擊者發(fā)送的請求信息是虛假的，所以服務器接收不到返回的確認信息，在一段時間內服務器會處與等待狀態(tài)，而分配給這次請求的資源卻被有被釋放

當被攻擊者等待一定的時間后，會因連接超時而斷開，這時攻擊者在次發(fā)送新的虛假信息請求，這樣最終服務器資源被耗盡，直到癱瘓

「DDOS：中文名稱是分布式拒絕服務攻擊」

指的是攻擊者控制多臺主機同時向同一主機或網絡發(fā)起DOS攻擊

DRDoS分布反射式拒絕服務攻擊這是DDoS攻擊的變形

「DDOS究竟如何攻擊」

目前最流行也是最好用的攻擊方法就是使用SYN-Flood進行攻擊，SYN-Flood也就是SYN洪水攻擊

SYN-Flood不會完成TCP三次握手的第三步，也就是不發(fā)送確認連接的信息給服務器，這樣，服務器無法完成第三次握手，但服務器不會立即放棄，服務器會不停的重試并等待一定的時間后放棄這個未完成的連接，這段時間叫做SYN timeout，這段時間大約30秒-2分鐘左右。

若是一個用戶在連接時出現(xiàn)問題導致服務器的一個線程等待1分鐘并不是什么大不了的問題，但是若有人用特殊的軟件大量模擬這種情況，那后果就可想而知了。一個服務器若是處理這些大量的半連接信息而消耗大量的系統(tǒng)資源和網絡帶寬，這樣服務器就不會再有空余去處理普通用戶的正常請求(因為客戶的正常請求比率很小)，這樣這個服務器就無法工作了，這種攻擊就叫做SYN-Flood攻擊

到目前為止，進行DDoS攻擊的防御還是比較困難的

首先，這種攻擊的特點是它利用了TCP/IP協(xié)議的漏洞，除非你不用TCP/IP，才有可能完全抵御住DDoS攻擊

不過這不等于我們就沒有辦法阻擋DDoS攻擊，我們可以盡力來減少DDoS的攻擊

「下面就是一些防御方法:」

1. 關閉不必要的服務

2. 限制同時打開的SYN半連接數(shù)目

3. 縮短SYN半連接的time out 時間

4. 正確設置防火墻

5. 禁止對主機的非開放服務的訪問

6. 限制特定IP地址的訪問

7. 啟用防火墻的防DDoS的屬性

Cookie和Session

Session 是「基于Cookie 實現(xiàn)」的另一種記錄服務端和客戶端會話狀態(tài)的機制。

Session 是存儲在服務端，而 SessionId 會被存儲在客戶端的 Cookie 中。

Session 的「認證過程」：

1. 客戶端第一次發(fā)送請求到服務端，服務端根據(jù)信息創(chuàng)建對應的 Session，并在響應頭返回 SessionID
2. 客戶端接收到服務端返回的 SessionID 后，會將此信息存儲在 Cookie 上，同時會記錄這個 SessionID 屬于哪個域名
3. 當客戶端再次訪問服務端時，請求會自動判斷該域名下是否存在 Cookie 信息，如果有則發(fā)送給服務端，服務端會從 Cookie 中拿到 SessionID，再根據(jù) SessionID 找到對應的 Session，如果有對應的 Session 則通過，繼續(xù)執(zhí)行請求，否則就中斷

「Cookie和Session的區(qū)別」

1. 安全性，因為 Cookie 可以通過客戶端修改，而 Session 只能在服務端設置，所以安全性比 Cookie 高，一般會用于驗證用戶登錄狀態(tài)
2. 適用性，Cookie 只能存儲字符串數(shù)據(jù)，而 Session 可以存儲任意類型數(shù)據(jù)
3. 有效期，Cookie 可以設置任意時間有效，而 Session 一般失效時間短

常見面試題

「在瀏覽器地址欄鍵入URL」

1.DNS解析：瀏覽器會依據(jù)URL逐層查詢DNS服務器緩存，解析URL中的域名對應的IP地址，DNS緩存從近到遠依次是瀏覽器緩存、系統(tǒng)緩存、路由器緩存、IPS服務器緩存、域名服務器緩存、頂級域名服務器緩存。

從哪個緩存找到對應的IP直接返回，不再查詢后面的緩存。

2.TCP連接：結合三次握手

3.發(fā)送HTTP請求：瀏覽器發(fā)出讀取文件的HTTP請求，該請求發(fā)送給服務器

4.服務器處理請求并返回HTTP報文：服務器對瀏覽器請求做出響應，把對應的帶有HTML文本的HTTP響應報文發(fā)送給瀏覽器

5.瀏覽器解析渲染頁面

6.連接結束：瀏覽器釋放TCP連接，該步驟即四次揮手。

第5步和第6步可以認為是同時發(fā)生的，哪一步在前沒有特別的要求