Ⅰ http和https的區別http與TCP/IP區別http/TCP三次握手四次揮手
https, 全稱Hyper Text Transfer Protocol Secure，相比http，多了一個secure，這一個secure是怎麼來的呢？這是由TLS（SSL）提供的，這個又是什麼呢？估計你也不想知道。大概就是一個叫openSSL的library提供的。https和http都屬於冊慎application layer，基於TCP（以及UDP）協議，但是又完全不一樣。TCP用的port是80， https用的是443（值得一提的是，google發明了一個新的協議，叫QUIC，並不基於TCP，用的port也是443， 同樣是用來給https的。谷歌好牛逼啊。）總體來說，https和http類似，但是比http安全。
http預設工作在TCP協議80埠(需要國內備案），用戶訪問網站http://打頭的都是標准http服務，http所封裝的信息都是明文的，通過抓包工具可以分析其信息內容，如果這些信息內容包含你的銀行卡賬號、密碼，你肯定無法接受這種服務，那有沒有可以加密這些敏感信息的服務呢？那就是https！
https是http運行在SSL/TLS之上，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的密鑰用伺服器方的證書進行了非對稱加密。此外客戶端可以驗證伺服器端的身份，如果配置了客戶端驗證，伺服器方也可以驗證客戶端的身份。
https預設工作在tcp協議443埠，它的工作流程一般如以下方式：
1、完成tcp三次同步握手；
2、客戶端驗證伺服器數字證書，通過，進入橘蔽步驟3；
3、DH演算法協商對稱加密演算法的密鑰、hash演算法的密鑰；
4、SSL安全加密隧道協商完成；
5、網頁以加密的方式傳輸，用協商的對稱加密演算法和密鑰加密，保證數據機密性；用協商的hash演算法進行數據完整性保護，保證數據不被篡改。
附：https一般使用的加密與hash演算法如下：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
hash演算法：MD5，SHA1，SHA256
如果https是網銀服務，以上SSL安全隧道成功建立才會要求用戶輸入賬戶信息，賬戶信息是在安全隧道里傳輸，所以不會泄密！
TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。Web使用HTTP協議作應用層協議，以封裝HTTP 文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。
下面的圖表試圖顯示不同的TCP/IP和其他的協議在最初OSI（Open System Interconnect）模型中的位置：
CA證書是什麼？
CA（Certificate Authority）是負責管理和簽發證書的第三方權威機構，是所有行業和公眾都信任的、認可的。
CA證書，就是CA頒發的證書，可用於驗證網站是否可信（針對HTTPS）、驗證某文件是否可信（是否被篡改）等，也可以用一個證書來證明另一個證書是真實可信，最頂級的證書稱為根證書。除了根證書（自己證明自己是可靠），其它證書都要依靠上一級的證書，來證明自己。
https大致過程：
1、建立伺服器443埠連接 ；
2、SSL握手：隨機數，證書，密鑰，加密演算法；
3、發送加密請求 ；
4、發送加密響應；
5、關閉SSL；
6、關閉TCP.
SSL握手大致過程：
1、客戶端發送隨機數1，支持的加密方法（如RSA公鑰加密）；
2、服務端發送隨機數2，和伺服器公鑰，並確認加密方法；
3、客戶端發送用伺服器公鑰加密的隨機數3；
4、伺服器用私鑰解密這個隨機數3，用加密方法計算生成對稱加密的密鑰給客戶端；
5、接下來的報文都用雙方協定好的加密方法和密鑰，進行加密.
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數圓姿州據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向位元組流，實際上是TCP把數據看成一連串無結構的位元組流（流模式）;UDP是面向報文的（報文模式），UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP要求系統資源較多，UDP較少。TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組
SYN：同步序列編號; ACK=1: 確認序號 ; FIN附加標記的報文段（FIN表示英文finish）
一個TCP連接必須要經過三次「對話」才能建立起來，其中的過程非常復雜，只簡單的 描述下這三次對話的簡單過程：主機A向主機B發出連接請求數據包：「我想給你發數據，可以嗎？」，這是第一次對話；主機B向主機A發送同意連接和要求同步 （同步就是兩台主機一個在發送，一個在接收，協調工作）的數據包：「可以，你什麼時候發？」，這是第二次對話；主機A再發出一個數據包確認主機B的要求同 步：「我現在就發，你接著吧！」，這是第三次對話。三次「對話」的目的是使數據包的發送和接收同步，經過三次「對話」之後，主機A才向主機B正式發送數據。
為什麼需要「三次握手」?
在謝希仁著《計算機網路》第四版中講「三次握手」的目的是「 為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤 」。在另一部經典的《計算機網路》一書中講「三次握手」的目的是為了解決「網路中存在延遲的重復分組」的問題。這兩種不一樣的表述其實闡明的是同一個問題。
謝希仁版《計算機網路》中的例子是這樣的，「已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。 本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。 採用「三次握手」的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。」。 主要目的防止server端一直等待，浪費資源。
為什麼需要「四次揮手」？
可能有人會有疑問，在tcp連接握手時為何ACK是和SYN一起發送，這里ACK卻沒有和FIN一起發送呢。原因是 因為tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，但是還是可以繼續發送數據。
握手，揮手過程中各狀態介紹:
3次握手過程狀態：
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連接了。
SYN_SENT : 當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。（發送端）
SYN_RCVD : 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最後一個 ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。（伺服器端）
ESTABLISHED ：這個容易理解了，表示連接已經建立了。
4次揮手過程狀態：（可參考下圖）：
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是： FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態， 當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
FIN_WAIT_2： 上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示 半連接 ，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍後再關閉連接。（主動方）
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文 ，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）
CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？ 當對方close一個SOCKET後發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，發送FIN報文給對方，也即關閉連接。 所以你在 CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。 （被動方）
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）
CLOSED: 表示連接中斷。
TCP的具體狀態圖可參考：