一. http協議
1. http協議的發展歷程以及每個版本存在的問題
1.1 http1.1優缺點
1.1.1 優點
- 針對tcp連接十分耗時，使用Connection: keep-alive增加了持久連接
- 增加管道機制，在1.0請求必須排隊發出的基礎上增加了管道機制，請求可以同時發出，但是響應必須按照請求發出的順序依次返回，性能在一定程度上得到了改善。
- 在1.0版本，服務器端必須等到一操作全部完成後，纔會向客戶端發送數據的基礎上增加了分塊傳輸，沒必要等待數據完全處理完畢再返回，服務器產生部分數據，那麼就發送部分數據。
1.1.2 缺點
- 高延遲 --帶來頁面加載速度的降低，這個缺陷主要由於隊頭堵塞導致的，請求必須排隊處理
- 無狀態特性 – 帶來巨大的 HTTP 頭部
- 明文傳輸 – 帶來不安全性
- 不支持服務器推送消息
1.2 http2 優缺點
1.2.1 http2優點
- 二進制傳輸，更利於計算機的解析
- 頭部壓縮，使用專門的 "HPACK”算法，在客戶端和服務器兩端建立“字典”，用索引號表示重複的字符串，還採用哈夫曼編碼來壓縮整數和字符串，可以達到 50%~90% 的高壓縮率。
- 多路複用，客戶端和服務端實現真正的全雙工通信
- 服務端推送，服務端不在被動等待客戶端請求，而是能夠主動向客戶端發送請求
1.2.2 http2缺點
- TCP 和 TCP+TLS 建立連接的延時
- TCP 的隊頭阻塞並沒有徹底解決
2. http2出現之前針對http連接無法複用缺陷的解決方案（移動端）
2.1 基於tcp的長鏈接
移動端app都會建立一條自己的長鏈接通道，通道的實現是基於tcp協議，基於tcp的socket編程技術難度相對複雜很多，而且需要自己制定協議，但帶來的回報也很大，目前淘寶應該有自己的協議。
2.2 長輪詢
客戶端在初始狀態就會發送一個polling請求到服務器，服務器並不會馬上返回業務數據，而是等待有新的業務數據產生的時候再返回。所以連接會一直被保持，一旦結束馬上又會發起一個新的polling請求，如此反覆，所以一直會有一個連接被保持。服務器有新的內容產生的時候，並不需要等待客戶端建立一個新的連接。它的缺點也很多，長連接增加server端壓力，斷網，重發機制，過期機制的設置
2.3 websocket
WebSocket和傳統的tcp socket連接相似，也是基於tcp協議，提供雙向的數據通道。WebSocket優勢在於提供了message的概念，比基於字節流的tcp socket使用更簡單，同時又提供了傳統的http所缺少的長連接功能.
二. https協議
https是在http上建立的ssl加密層，對傳輸的數據進行加密，是http協議的安全版，https協議的主要功能都依賴於TLS/SSL協議，TLS/SSL的功能實現主要依賴於散列算法/ 對稱加密算法/非對稱加密算法，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性
2.1 http的存在的問題
- 使用明文通信，內容可能被竊取（數據泄露/數據篡改/流量劫持等）
- 無法證明報文的完整性，所以可能遭到篡改，也就說說沒有辦法確認發出和請求到的報文前後是i相同的
- 不驗證通信雙方的身份，因此有可能遭遇到僞裝，http無法驗證通信方的身份，任何人都可以僞造虛假服務器欺騙用戶。
2.2 https協議的構建
針對明文通信，內容可能被竊取：採用對稱加密+非對稱，對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可以使得傳輸的內容不能被破解，因爲就算你攔截到了數據，但是沒有對應的私鑰，也是不能破解內容的。https將對稱加密與非對稱加密結合起來,充分利用兩者各自的優勢，在交換密鑰環節使用非對稱加密方式，之後的建立通信交換報文階段則使用對稱加密方式。
針對無法證明報文的完整性/身份驗證：：採用校驗數字簽名，將一段文本先用Hash函數生成消息摘要，然後用發送者的私鑰加密生成數字簽名，與原文文一起傳送給接收者。接下來就是接收者校驗數字簽名的流程了。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與上一步得到的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。
這裏的私鑰和公鑰採用的證書頒發機構的方式。
2.3 https協議的工作流程
1.Client發起一個HTTPS，根據RFC2818的規定，Client知道需要連接Server的443（默認）端口。
2.Server把事先配置好的公鑰證書（public key certificate）返回給客戶端。
3.Client驗證公鑰證書：比如是否在有效期內，證書的用途是不是匹配Client請求的站點，是不是在CRL吊銷列表裏面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操作系統內置的Root證書或者Client內置的Root證書）。如果驗證通過則繼續，不通過則顯示警告信息。
4.Client使用僞隨機數生成器生成加密所使用的對稱密鑰，然後用證書的公鑰加密這個對稱密鑰，發給Server。
5.Server使用自己的私鑰（private key）解密這個消息，得到對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。
6.Server使用對稱密鑰加密“明文內容A”，發送給Client。
7.Client使用對稱密鑰解密響應的密文，得到“明文內容A”。
8.Client再次發起HTTPS的請求，使用對稱密鑰加密請求的“明文內容B”，然後Server使用對稱密鑰解密密文，得到“明文內容B”。
2.4 https協議和http的區別
- HTTPS比HTTP更加安全，對搜索引擎更友好，利於SEO,谷歌、百度優先索引HTTPS網頁;
- HTTPS需要用到SSL證書，而HTTP不用;
- HTTPS標準端口443，HTTP標準端口80;
- HTTPS基於傳輸層，HTTP基於應用層;
- HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;
三. tcp協議
3.1 三次握手
- 客戶端發送syn包（syn=x）到服務器，併入SYN_SEND狀態，等待服務器確認
- 服務器收入syn包，必須確認客戶的SYN（ACK/ack=j+1），同時自己也發送一個SYN包（syn=k），既SYN+ACK包，此時服務器進入SYN_RECV狀態。
- 客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK（ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手
3.2 四次揮手
- 客服端調用close等函數主動關閉, 並向服務端發送一個含FIN(seq=x)的報文, 然後就進入FIN-WAIT1階段,
- 服務端接收到對端的FIN後, 立馬向對端回一個ACK(ack=x+1,seq=y)確認, 然後進入CLOSE-WAIT階段, 該階段服務端還能夠將沒有發送完的數據發送給對端. 當服務端將數據發送完後再發送一個FIN段, 之後進入LAST-ACK階段
- 客戶端接收到對端的ACK時, 進入FIN-WAIT2階段, 該階段客服端還能夠繼續接收數據, 但是不能在發送數據了;
- 服務端的數據傳輸完了之後，向客戶端發送FIN和ACK(FIN=1, ack = x+1,seq =k), 之後客戶端進入TIME_WAIT階段. 等待2MSL後客戶端徹底關閉.
- 客戶端收到服務端的關閉報文之後，發送ACK=1, ack= k+1, 服務端收到後完全關閉該連接。
3.3 三次握手和四次揮手的問題
【問題1】爲什麼三次握手？
爲了讓客戶端和服務端都能確認自己能正常接收/發送報文，防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
（client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據）
【問題2】爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
答：因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
【問題3】爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回覆，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重複發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。
【問題4】如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接
3.4 tcp的可靠傳輸是怎麼保證的？
- 確認和重傳：接收方收到報文就會確認，發送方發送一段時間後沒有收到確認就重傳。
- .數據校驗
- 數據合理分片和排序，TCP會按MTU合理分片，接收方會緩存未按序到達的數據，重新排序後再交給應用層
- 流量控制，運用TCP報文段中的窗口大小字段來控制，發送方的發送窗口不可以大於接受方發回的窗口大小。
- 擁塞控制：當網絡擁塞時，減少數據的發送。
總結一下步驟：
-
在傳遞數據之前，會有三次握手來建立連接。
-
應用數據被分割成TCP認爲最適合發送的數據塊（按字節編號，合理分片）。這和UDP完全不同，應用程序產生的數據報長度將保持不變。（將數據截斷爲合理的長度）
-
當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。（超時重發）
-
當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒。（對於收到的請求，給出確認響應）（之所以推遲，可能是對包做完整校驗）
-
TCP將保持它首部和數據的校驗和。這是一個端到端的校驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的校驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。（校驗出包有錯，丟棄報文段，不給出響應，TCP發送數據端，超時時會重發數據）
-
既然TCP報文段作爲IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層。（對失序數據進行重新排序，然後才交給應用層）
-
既然IP數據報會發生重複，TCP連接的接收端必須丟棄重複的數據。（對於重複數據，能夠丟棄重複數據）
-
TCP還能提供流量控制。TCP連接的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端發送接收端緩衝區所能容納的數據。這將防止較快主機致使較慢主機的緩衝區溢出。（TCP可以進行流量控制，防止較快主機致使較慢主機的緩衝區溢出），TCP使用的流量控制協議是可變大小的滑動窗口協議。
-
TCP還能提供擁塞控制。當網絡阻塞時，減少數據的發送。