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(應用層) 和TCP(傳輸層)之間插入一個SSL協(xié)議, 就是https确憨。一句話：http+加密+認證+完整性保護=https
http缺省工作在TCP協(xié)議80端口(需要國內備案），用戶訪問網站http://打頭的都是標準http服務瓤的，http所封裝的信息都是明文的休弃，通過抓包工具可以分析其信息內容，如果這些信息內容包含你的銀行卡賬號圈膏、密碼塔猾，你肯定無法接受這種服務，那有沒有可以加密這些敏感信息的服務呢稽坤？那就是https丈甸！
https是http運行在SSL/TLS之上，SSL/TLS運行在TCP之上尿褪。所有傳輸?shù)膬热荻冀涍^加密睦擂，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密茫多。此外客戶端可以驗證服務器端的身份祈匙，如果配置了客戶端驗證，服務器方也可以驗證客戶端的身份。
https缺省工作在tcp協(xié)議443端口夺欲，它的工作流程一般如以下方式：
1跪帝、完成tcp三次同步握手；
2些阅、客戶端驗證服務器數(shù)字證書伞剑，通過，進入步驟3市埋；
3黎泣、DH算法協(xié)商對稱加密算法的密鑰、hash算法的密鑰缤谎；
4抒倚、SSL安全加密隧道協(xié)商完成；
5坷澡、網頁以加密的方式傳輸托呕，用協(xié)商的對稱加密算法和密鑰加密，保證數(shù)據(jù)機密性频敛；用協(xié)商的hash算法進行數(shù)據(jù)完整性保護项郊，保證數(shù)據(jù)不被篡改。
附：https一般使用的加密與hash算法如下：
非對稱加密算法：RSA斟赚，DSA/DSS
對稱加密算法：AES着降，RC4，3DES
hash算法：MD5拗军，SHA1任洞，SHA256
如果https是網銀服務，以上SSL安全隧道成功建立才會要求用戶輸入賬戶信息食绿，賬戶信息是在安全隧道里傳輸侈咕，所以不會泄密！
HTTP與TCP/IP區(qū)別器紧？
TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網絡中傳輸楼眷，而HTTP是應用層協(xié)議铲汪，主要解決如何包裝數(shù)據(jù)。Web使用HTTP協(xié)議作應用層協(xié)議罐柳，以封裝HTTP 文本信息掌腰，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網絡上。
下面的圖表試圖顯示不同的TCP/IP和其他的協(xié)議在最初OSI（Open System Interconnect）模型中的位置：
CA證書是什么张吉？
CA（Certificate Authority）是負責管理和簽發(fā)證書的第三方權威機構齿梁，是所有行業(yè)和公眾都信任的、認可的。
CA證書勺择，就是CA頒發(fā)的證書创南，可用于驗證網站是否可信（針對HTTPS）、驗證某文件是否可信（是否被篡改）等省核，也可以用一個證書來證明另一個證書是真實可信稿辙，最頂級的證書稱為根證書。除了根證書（自己證明自己是可靠）气忠，其它證書都要依靠上一級的證書邻储，來證明自己。
https和ssl在握手方向有什么區(qū)別：
https大致過程：
1旧噪、建立服務器443端口連接 吨娜；
2、SSL握手：隨機數(shù)淘钟，證書萌壳，密鑰，加密算法日月；
3袱瓮、發(fā)送加密請求 ；
4爱咬、發(fā)送加密響應尺借；
5、關閉SSL精拟；
6燎斩、關閉TCP.
SSL握手大致過程：
1、客戶端發(fā)送隨機數(shù)1蜂绎，支持的加密方法（如RSA公鑰加密）栅表；
2、服務端發(fā)送隨機數(shù)2师枣，和服務器公鑰怪瓶，并確認加密方法；
3践美、客戶端發(fā)送用服務器公鑰加密的隨機數(shù)3洗贰；
4、服務器用私鑰解密這個隨機數(shù)3陨倡，用加密方法計算生成對稱加密的密鑰給客戶端敛滋；
5、接下來的報文都用雙方協(xié)定好的加密方法和密鑰兴革，進行加密.
TCP與UDP區(qū)別總結：
1绎晃、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的蜜唾，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務庶艾。也就是說袁余，通過TCP連接傳送的數(shù)據(jù)，無差錯落竹，不丟失泌霍，不重復，且按序到達;UDP盡最大努力交付述召，即不保證可靠交付
3朱转、TCP面向字節(jié)流，實際上是TCP把數(shù)據(jù)看成一連串無結構的字節(jié)流（流模式）;UDP是面向報文的（報文模式）积暖，UDP沒有擁塞控制藤为，因此網絡出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如IP電話夺刑，實時視頻會議等）
4缅疟、每一條TCP連接只能是點到點的;UDP支持一對一，一對多遍愿，多對一和多對多的交互通信
5存淫、TCP要求系統(tǒng)資源較多，UDP較少沼填。TCP首部開銷20字節(jié);UDP的首部開銷小桅咆，只有8個字節(jié)
TCP三次握手四次揮手:
SYN：同步序列編號; ? ACK=1: 確認序號 ; ?FIN附加標記的報文段（FIN表示英文finish）
一個TCP連接必須要經過三次“對話”才能建立起來，其中的過程非常復雜坞笙，只簡單的 描述下這三次對話的簡單過程：主機A向主機B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)岩饼，可以嗎？”薛夜，這是第一次對話籍茧；主機B向主機A發(fā)送同意連接和要求同步 （同步就是兩臺主機一個在發(fā)送，一個在接收梯澜，協(xié)調工作）的數(shù)據(jù)包：“可以寞冯，你什么時候發(fā)？”腊徙，這是第二次對話简十；主機A再發(fā)出一個數(shù)據(jù)包確認主機B的要求同 步：“我現(xiàn)在就發(fā)，你接著吧撬腾！”，這是第三次對話恢恼。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步民傻，經過三次“對話”之后，主機A才向主機B正式發(fā)送數(shù)據(jù)。
為什么需要“三次握手”?
? ? ? ? ? ? 在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務端漓踢，因而產生錯誤”牵署。在另一部經典的《計算機網絡》一書中講“三次握手”的目的是為了解決“網絡中存在延遲的重復分組”的問題。這兩種不一樣的表述其實闡明的是同一個問題喧半。
??????????? 謝希仁版《計算機網絡》中的例子是這樣的奴迅，“已失效的連接請求報文段”的產生在這樣一種情況下：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并沒有要求建立連接棺禾∽禾悖”。主要目的防止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)奶躯，表示服務器端的某個SOCKET處于監(jiān)聽狀態(tài)帚桩，可以接受連接了。?
SYN_SENT: 當客戶端SOCKET執(zhí)行CONNECT連接時嘹黔，它首先發(fā)送SYN報文账嚎，因此也隨即它會進入到了SYN_SENT狀態(tài)，并等待服務端的發(fā)送三次握手中的第2個報文儡蔓。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報文郭蕉。（發(fā)送端）
SYN_RCVD: 這個狀態(tài)與SYN_SENT遙想呼應這個狀態(tài)表示接受到了SYN報文，在正常情況下浙值，這個狀態(tài)是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態(tài)恳不，很短暫，基本上用netstat你是很難看到這種狀態(tài)的开呐，除非你特意寫了一個客戶端測試程序烟勋，故意將三次TCP握手過程中最后一個 ACK報文不予發(fā)送。因此這種狀態(tài)時筐付，當收到客戶端的ACK報文后卵惦，它會進入到ESTABLISHED狀態(tài)。（服務器端）
ESTABLISHED：這個容易理解了瓦戚，表示連接已經建立了沮尿。
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)實際上是當SOCKET在ESTABLISHED狀態(tài)時畜疾，它想主動關閉連接，向對方發(fā)送了FIN報文印衔，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)啡捶。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態(tài)奸焙，當然在實際的正常情況下瞎暑，無論對方何種情況下，都應該馬上回應ACK報文与帆，所以FIN_WAIT_1狀態(tài)一般是比較難見到的了赌，而FIN_WAIT_2狀態(tài)還有時常常可以用netstat看到玄糟。（主動方）
FIN_WAIT_2：上面已經詳細解釋了這種狀態(tài)勿她，實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接阵翎，也即有一方要求close連接嫂拴，但另外還告訴對方播揪，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)贮喧，稍后再關閉連接筒狠。（主動方）
TIME_WAIT:?表示收到了對方的FIN報文，并發(fā)送出了ACK報文箱沦，就等2MSL后即可回到CLOSED可用狀態(tài)了辩恼。如果FIN_WAIT_1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時谓形，可以直接進入到TIME_WAIT狀態(tài)灶伊，而無須經過FIN_WAIT_2狀態(tài)。（主動方）
CLOSING（比較少見）: 這種狀態(tài)比較特殊寒跳，實際情況中應該是很少見聘萨，屬于一種比較罕見的例外狀態(tài)。正常情況下童太，當你發(fā)送FIN報文后米辐，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文书释。但是CLOSING狀態(tài)表示你發(fā)送FIN報文后翘贮，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文爆惧。什么情況下會出現(xiàn)此種情況呢狸页？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話扯再，那么就出現(xiàn)了雙方同時發(fā)送FIN報文的情況芍耘，也即會出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關閉SOCKET連接熄阻。
CLOSE_WAIT: 這種狀態(tài)的含義其實是表示在等待關閉斋竞。怎么理解呢？當對方close一個SOCKET后發(fā)送FIN報文給自己饺律，你系統(tǒng)毫無疑問地會回應一個ACK報文給對方窃页，此時則進入到CLOSE_WAIT狀態(tài)。接下來呢复濒，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方脖卖，如果沒有的話，那么你也就可以 close這個SOCKET巧颈，發(fā)送FIN報文給對方畦木，也即關閉連接。所以你在CLOSE_WAIT狀態(tài)下砸泛，需要完成的事情是等待你去關閉連接十籍。（被動方）
LAST_ACK: 這個狀態(tài)還是比較容易好理解的蛆封，它是被動關閉一方在發(fā)送FIN報文后，最后等待對方的ACK報文勾栗。當收到ACK報文后惨篱，也即可以進入到CLOSED可用狀態(tài)了。（被動方）
CLOSED: 表示連接中斷围俘。
TCP的具體狀態(tài)圖可參考：
