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