TCP
基本概念
| 字段 | 含義 |
| URG | 緊急指針是否有效。為1，表示某一位需要被優先處理 |
| ACK | 确認号是否有效，一般置為1 |
| PSH | 提示接收端應用程式立即從TCP緩沖區把資料讀走 |
| RST | 對方要求重建立立連接配接，複位 |
| SYN | 請求建立連接配接，并在其序列号的字段進行序列号的初始值設定。建立連接配接，設定為1 |
| FIN | 希望斷開連接配接 |
三次握手與四次揮手
| 三次握手 | 四次揮手 |
 |  |
TIME_WAIT
TCP 四次握手結束後，連接配接雙方都不再交換消息，但主動關閉的一方保持這個連接配接在一段時間内不可用。為什麼呢？
假設A、B來代指 TCP 連接配接的兩端，A 為主動關閉的一端，通過以下兩種情況分析：
- 四次揮手中，A 發 FIN， B 響應 ACK，B 再發 FIN，A 響應 ACK 實作連接配接的關閉。而如果 A 響應的 ACK 包丢失，B 會以為 A 沒有收到自己的關閉請求，然後會重試向 A 再發 FIN 包。如果沒有 TIME_WAIT 狀态，A 不再儲存這個連接配接的資訊，收到一個不存在的連接配接的包，A 會響應 RST 包，導緻 B 端異常響應。此時， TIME_WAIT 是為了保證全雙工的 TCP 連接配接正常終止
- 如果沒有TIME_WAIT的存在，或者說停留在TIME_WAIT上的時間很短，則主動關閉的一方很快就進入了CLOSED狀态。如果此時建立一個連接配接，源随機端口如果被複用，在connect發送SYN包後，由于被動方仍認為這條連接配接【五元組】還在等待ACK，但是卻收到了SYN，則被動方會回複RST，造成主動建立連接配接的一方由于收到了RST，連接配接無法成功
- TCP 下的 IP 層協定是無法保證包傳輸的先後順序的。如果雙方揮手之後，一個網絡四元組（src/dst ip/port）被回收，而此時網絡中還有一個遲到的資料包沒有被 B 接收，A 應用程式又立刻使用了同樣的四元組再建立了一個新的連接配接後，這個遲到的資料包才到達 B，那麼這個資料包就會讓 B 以為是 A 剛發過來的。此時， TIME_WAIT 的存在是為了保證網絡中迷失的資料包正常過期
結合以上三種情況，TIME_WAIT 狀态的保持時長為2MSL也就可以了解了。MSL（Maximum Segment Lifetime），最大分段壽命，它表示一個 TCP 分段可以存在于網際網路系統中的最大時間，由 TCP 的實作，超出這個壽命的分片都會被丢棄。一來一去兩個來回即2MSL，RFC裡建議的MSL其實是2分鐘，但是很多實作都是30秒，可以通過
/proc/sys/net/ipv4/tcp_fin_timeout
這個檔案檢視和修改這個值。
HTTP和HTTPS協定
發展曆史
| 版本 | 産生時間 | 内容 | 發展現狀 |
| HTTP/0.9 | 1991年 | 不涉及資料包傳輸，規定用戶端和伺服器之間通信格式，隻能GET請求 | 沒有作為正式的标準 |
| HTTP/1.0 | 1996年 | 傳輸内容格式不限制，增加PUT、PATCH、HEAD、 OPTIONS、DELETE指令 | 正式作為标準 |
| HTTP/1.1 | 1997年 | 持久連接配接(長連接配接)、節約帶寬、HOST域、管道機制、分塊傳輸編碼 | 2015年前使用最廣泛 |
| HTTP/2 | 2015年 | 多路複用、伺服器推送、頭資訊壓縮、二進制協定等 | 逐漸覆寫市場 |
HTTP/1.1和HTTP/2比對
多路複用：通過單一的HTTP/2連接配接請求發起多重的請求-響應消息，多個請求stream共享一個TCP連接配接，實作多留并行而不是依賴建立多個TCP連接配接
HTTP和HTTPS比對
HTTP特點：
- 無狀态：協定對用戶端沒有狀态存儲，對事物處理沒有“記憶”能力，比如通路一個網站需要反複進行登入操作（通過Cookie/Session技術解決）
- 無連接配接：HTTP/1.1之前，由于無狀态特點，每次請求需要通過TCP三向交握四次揮手，和伺服器重建立立連接配接（HTTP/1.1提供HTTP keep-alive機制）
- 基于請求和響應：基本的特性，由用戶端發起請求，服務端響應
- 簡單快速、靈活
- 通信使用明文、請求和響應不會對通信方進行确認、無法保護資料的完整性
HTTPS特點：
基于HTTP協定，通過SSL或TLS提供加密處理資料、驗證對方身份以及資料完整性保護，整個過程如下：
- client向server的443端口發送消息，主要包含随機值1和用戶端支援的加密算法
- server接收到資訊之後給予client響應握手資訊，包括随機值2和比對好的協商加密算法
- 随即server給client發送第二個響應封包是數字證書。服務端必須要有一套數字證書，可以自己制作，也可以向組織申請。差別就是自己頒發的證書需要用戶端驗證通過，才可以繼續通路，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。傳送證書，這個證書其實就是公鑰，隻是包含了很多資訊，如證書的頒發機構、過期時間、服務端的公鑰、第三方證書認證機構(CA)的簽名、服務端的域名資訊等内容
- 用戶端解析證書，這部分工作是由用戶端的TLS來完成的，首先會驗證公鑰是否有效（通過用戶端内置的CA公鑰解密數字簽名得到摘要資訊對比驗證），比如頒發機構、過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個随即值（預主秘鑰）
- 用戶端認證證書通過之後，接下來是通過随機值1、随機值2和預主秘鑰組裝會話秘鑰，然後通過證書的公鑰加密會話秘鑰（非對稱加密）
- 傳送加密資訊，這部分傳送的是用證書公鑰加密後的會話秘鑰，目的就是讓服務端使用秘鑰解密得到随機值1、随機值2和預主秘鑰
- 服務端解密得到随機值1、随機值2和預主秘鑰，然後組裝會話秘鑰，跟用戶端會話秘鑰相同（對稱加密）
- 用戶端通過會話秘鑰加密一條消息發送給服務端，主要驗證服務端是否正常接受用戶端加密的消息
- 同樣服務端也會通過會話秘鑰加密一條消息回傳給用戶端，如果用戶端能夠正常接受的話表明SSL層連接配接建立完成了
HTTPS安全政策：
- 混合加密：結合非對稱加密和對稱加密技術。用戶端使用對稱加密生成會話密鑰對傳輸資料進行加密，然後使用非對稱加密的公鑰再對秘鑰進行加密。是以網絡上傳輸的資料是被對稱加密秘鑰加密的密文和用非對稱加密公鑰加密後的秘密秘鑰。是以即使被黑客截取，由于沒有私鑰，無法擷取到加密明文的秘鑰，便無法擷取到明文資料
- 數字摘要：通過單向hash函數對原文進行哈希，将需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一緻，并且即使知道了摘要也不能反推出明文
- 數字簽名技術：數字簽名建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術
如何確定證書的安全性？
- 當用戶端收到這個證書之後，使用本地配置的權威機構的公鑰對證書進行解密得到服務端的公鑰和證書的數字簽名，數字簽名經過CA公鑰解密得到證書資訊摘要
- 然後計算一下目前證書的資訊摘要，與收到的資訊摘要作對比，如果一樣，表示證書一定是伺服器下發的，沒有被中間人篡改過。因為中間人雖然有權威機構的公鑰，能夠解析證書内容并篡改，但是篡改完成之後中間人需要将證書重新加密，但是中間人沒有權威機構的私鑰，無法加密，強行加密隻會導緻用戶端無法解密，如果中間人強行亂修改證書，就會導緻證書内容和證書簽名不比對