請點贊，你的點贊對我意義重大，滿足下我的虛榮心。
??常在河邊走，哪有不濕鞋。或許面試過程中你遇到的問題就在這呢？
??關注我個人簡介，面試不迷路~

一、請你描述TCP三次握手與四次揮手的過程與意義

這道題想考察什么？

這個問題屬于網絡體系中的基礎理論知識，對于這種類型的問題如果沒有一個清晰的認識，那會讓你在掌握一些“高大上“技術的時沒有支撐，也難以把整體框架理順。比如Http、RTSP 、RTMP等被廣泛運用的應用層協議都是基于TCP來實現的。所以被問到這個問題并不稀奇。

考察的知識點

網絡的基礎知識

考生如何回答

TCP/IP協議定義了計算機在網絡中如何發送數據、數據格式如何定義、發出消息后在網絡中如何尋址找到目標計算機，最后目標計算機又如何檢驗收到消息的正確性、對數據拆解最后得到消息內容的一套處理標準。

有了這些標準后生產提供TCP/IP服務的軟件商家就有了一套統一的規范，只要遵循這個規范去實現自己的軟件功能。

三次握手

在進行業務通信前，必須建立好連接，而TCP/IP連接的建立需要經過三次握手的過程。其過程如下圖：

image.png

1. 第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，并進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
2. 第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
3. 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。

為什么要三次握手？

全雙工通信

三次握手是確定通信雙方通訊線路是全雙工的最小次數，全雙工通信是指：通信的雙方可以同時發送和接收信息 。

正如雙方電話通話：

A：喂，能聽到嗎？

B：可以

此時如果A沒有反饋，B無法確定A是否能夠接收數據。

保證可靠性

另外TCP是可靠傳輸協議，保證通信的可靠性的手段中包含序列號與確認應答機制。

• 序列號：TCP傳輸時將每個字節的數據都進行了編號，保證數據的有序性與可靠性（當接收到的數據總少了某個序號的數據時，能馬上知道 ）；
• 確認應答：TCP傳輸的過程中，每次接收方收到數據后，都會對傳輸方進行確認應答。也就是發送ACK報文。這個ACK報文當中帶有對應的確認序列號，告訴發送方，接收到了哪些數據，下一次的數據從哪里發。

而三次握手的同時也能確定通信雙方的初始序列號。

1. C --> S SYN my sequence number is X
2. S <-- C ACK your sequence number is X my sequence number is Y
3. C --> S ACK your sequence number is Y

如果C 未確認收到 B 的。也就是說，只有 C 發送給 S 的包都是可靠的， 而 S 發送給 C 的則不是，所以這不是可靠的連接。

避免資源浪費

除此之外，第一次握手：客戶端發送連接請求消息到服務端，服務端收到信息后需要進行第二次握手：應答告知客戶端已經接收連接請求。而服務端發送出去的應答消息，需要等客戶端第三次握手響應后，才能確定此次連接為有效連接。

若客戶端發出去的第一個連接請求由于某些原因在網絡節點中滯留了導致延遲，直到客戶端放棄連接后的某個時間點才到達服務端，這是一個早已失效的報文，但是此時服務端仍然認為這是客戶端的建立連接請求第一次握手，于是服務端第二次握手回應了客戶端。如果沒有第三次握手，那么到這里，連接就建立了，但是此時客戶端并沒有任何數據要發送，會讓服務端空等，造成資源浪費。

四次揮手

在完成數據交互之后，如果選擇關閉連接，以回收資源，則完成四次揮手來進行“和平分手”。過程如下圖：

image.png

1. 第一次揮手：主動關閉方發送第一個包，其中FIN標志位為1，發送順序號seq為X。
2. 第二次揮手：被動關閉方收到FIN包后發送第二個包，其中發送順序號seq為Z，接收順序號ack為X+1。
3. 第三次揮手：被動關閉方再發送第三個包，其中FIN標志位為1，發送順序號seq為Y，接收順序號ack為X。
4. 第四次揮手：主動關閉方發送第四個包，其中發送順序號為X，接收順序號為Y。至此，完成四次揮手。

為什么斷開連接需要四次揮手？

三次握手是因為建立連接時，ACK和SYN可以放在一個報文里來發送。而關閉連接時，被動關閉方可能還需要發送一些數據后，再發送FIN報文表示同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。因此斷開連接需要4次。

二、談談你對TCP與UDP的區別是什么的理解（騰訊）

這道題想考察什么？

在平時的開發中大多數情況下都是使用Http/Https協議完成與服務端的網絡交互，而Http底層是基于TCP的可靠連接。而TCP/IP 中有兩個具有代表性的傳輸層協議，分別是 TCP 和 UDP。掌握二者的區別能夠讓我們在不同的場景中合理的選擇最優的傳輸協議。

考察的知識點

網絡的基礎知識

考生如何回答

TCP/IP 是互聯網相關的各類協議簇的總稱，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都屬于 TCP/IP 協議簇 。之所以命名為TCP/IP協議，因為TCP、IP協議是兩個很重要的協議，就用他兩命名了。

UDP

UDP協議全稱是用戶數據報協議（User Data Protocol），在網絡中它與TCP協議一樣用于處理數據包，是一種無連接的協議。在OSI模型中，在第四層—傳輸層，處于IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。

它有以下幾個特點：

• 面向無連接

  首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。并且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。

  具體來說就是：

  • 在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然后就傳遞給網絡層了
  • 在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作

• 有單播，多播，廣播的功能

  UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

• UDP是面向報文的

  發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文

• 不可靠性

  首先不可靠性體現在無連接上，UDP只會把想發的數據報文一股腦的丟給對方，并不在意數據有無安全完整到達。 通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。

  并且收到什么數據就傳遞什么數據，并且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。

  再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恒定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。

• 頭部開銷小，傳輸數據報文時是很高效的。

[圖片上傳失敗...(image-220252-1685191214835)]

UDP 頭部包含了以下幾個數據：

1. 兩個十六位的端口號，分別為源端口（可選字段）和目標端口

2. 整個數據報文的長度

3. 整個數據報文的檢驗和（IPv4 可選 字段），該字段用于發現頭部信息和數據中的錯誤

因此 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。

TCP

TCP協議全稱是傳輸控制協議（Transmission Control Protocol ），是一種面向連接的、可靠的、基于字節流的傳輸層通信協議，由 IETF 的RFC 793定義。TCP 是面向連接的、可靠的流（不間斷的數據結構）協議。

TCP連接過程見：描述TCP三次握手與四次揮手的過程與意義

它有以下幾個特點：

• 面向連接

  面向連接，是指發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎。

• 僅支持單播傳輸

  每條TCP傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。

• 面向字節流

  TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以字節流方式進行傳輸。

• 可靠傳輸

  對于可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳。

• 提供擁塞控制

  當網絡出現擁塞的時候，TCP能夠減小向網絡注入數據的速率和數量，緩解擁塞

• TCP提供全雙工通信

  TCP允許通信雙方的應用程序在任何時候都能發送數據，因為TCP連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決于MSS）

TCP和UDP的比較

總結

• TCP向上層提供面向連接的可靠服務 ，UDP向上層提供無連接不可靠服務。
• 雖然 UDP 并沒有 TCP 傳輸來的準確，但是也能在很多實時性要求高的地方有所作為
• 對數據準確性要求高，速度可以相對較慢的，可以選用TCP

三、談談你對TCP 流量控制與擁塞控制的理解（oppo）

這道題想考察什么？

網絡編程，TCP原理

考察的知識點

TCP流量控制與擁塞控制

考生應該如何回答

TCP的擁塞控制和流量控制雖然采取的動作很相似，但擁塞控制與網絡的擁堵情況相關聯，而流量控制與接收方的緩存狀態相關聯，是針對完全不同的問題而采取的措施 。兩者從不同的方面保證TCP協議可靠性。

流量控制

雙方在通信的時候，發送方的速率與接收方的速率是不一定相等，如果發送方的發送速率太快，會導致接收方處理不過來，這時候接收方只能把處理不過來的數據存在緩存區里。

如果緩存區滿了發送方還在瘋狂著發送數據，接收方只能把收到的數據包丟掉，而流量控制就是控制發送者的發送速度從而使接收者來得及接收，防止丟失數據包的。

假設沒有流量控制，發送端根據自己的實際情況發送數據，如果發送的速度太快，導致接收端的接收緩沖區很快填滿了，此時發送端如果繼續發送數據，接收端處理不過來，這時接收端就會把本來應該接收的數據丟棄，這會觸發發送端的重發機制，從而導致網絡流量的無端浪費。

滑動窗口

在TCP頭中有一個Window字段，這個字段代表了接收端告訴發送端自己緩沖區還有多少剩余空間可以接收數據。TCP 利用滑動窗口實現流量控制的機制， 而滑動窗口大小就是通過TCP頭部的Window字段來通知發送方。

接收端會在確認應答發送ACK報文時，將自己的即時窗口大小填入，并跟隨ACK報文一起發送過去。而發送方根據ACK報文里的窗口大小的值進而改變自己的發送速度。

image.png

假設我們窗口大小為20（32-51），發送方發送32-51序列包后，接收到ACK=36，表示 接收方只接收到了32-35，下一次接收方期望接收到的是36序列號的包。如果接收方給到的ACK中窗口大小仍為20，發送方窗口滑動，36-55則是發送方可以發送的包。

這就是滑動窗口的工作機制，發送方在發送過程中始終保持著一個發送窗口，只有落在發送窗口內的幀才允許被發送；發送方收到ACK 計算獲得接收方窗口大小之后，便會調整自己的發送速率，也就是調整自己發送窗口的大小實現流量控制。但是當發送方收到接收窗口的大小為0時，發送方就會停止發送數據！

零窗口

當發送方停止發送數據后，該怎樣才能知道自己可以繼續發送數據？

我們可以采用這樣的策略：當接收方處理好數據，接受窗口 win > 0 時，接收方發個通知報文去通知發送方，告訴他可以繼續發送數據了。當發送方收到窗口大于0的報文時，就繼續發送數據。

不過這時候可能會遇到一個問題，如果發送端在重發超時的時間內都沒有收到窗口更新的通知或者窗口更新的包丟失了，這時候就會引發一個問題：接收方發了通知報文后，繼續等待發送方發送數據，而發送方則在等待接收方的通知報文，此時雙方會陷入一種僵局。

為了解決這種問題，TCP為每一個連接設有一個持續計時器 ：當發送方收到接受窗口 win = 0 時，這時發送方停止發送報文，并且同時開啟一個定時器，每隔一段時間就發個測試報文去詢問接收方，打聽是否可以繼續發送數據了，如果可以，接收方就告訴他此時接受窗口的大小；如果接受窗口大小還是為0，則發送方再次刷新啟動定時器。

擁塞控制

流量控制是接收方怕發送方發的太快，使得自己來不及處理。而擁塞控制的對象是網絡，怕發送方發的太快，造成網絡擁塞，使得網絡來不及處理，是一個全局性的過程。

擁塞控制就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。 擁塞是一個動態問題，我們沒有辦法用一個靜態方案去解決，從這個意義上來說，擁塞是不可避免的。就好像上下班高峰期經常堵車，為了不讓交通癱瘓，交警會去現場指揮，采用動態的方式對車輛進行限制，根據實際情況，慢慢放行。

比如主機A給主機B傳輸數據。

兩臺主機在傳輸數據包的時候，如果發送方遲遲沒有收到接收方反饋的ACK，那么發送方就會認為它發送的數據包丟失了，進而會重新傳輸這個丟失的數據包。

然而實際情況有可能此時有太多主機正在使用信道資源，導致網絡擁塞了，而A發送的數據包被堵在了半路，遲遲沒有到達B。這個時候A誤認為是發生了丟包情況，會重新傳輸這個數據包。

結果就是不僅浪費了信道資源，還會使網絡更加擁塞。因此，我們需要進行擁塞控制。TCP的擁塞控制通過：慢啟動、擁塞避免、快重傳與快恢復完成。

慢啟動

慢啟動算法為TCP發送方新增的一個擁塞窗口 （cwnd ）。對應到流量控制，發送方會根據擁塞窗口和滑動窗口的最小值作為發送上限。

當新建連接時，發送方不了解網絡的情況，cwnd（擁塞窗口）初始化比較小的值，RFC建議2-4個MSS，具體視MSS的大小而定。

MSS：Maximum Segment Size，TCP一次傳輸發送的最大數據段長度。

假設初cwnd為1個MSS。發送端開始按照擁塞窗口大小發送數據，如果被ACK，下次就發送2個。如果還是收到了ACK，則發送4個，接著8個......。這樣cwnd的值就隨著網絡往返時間(Round Trip Time,RTT)呈指數級增長，事實上，慢啟動的速度一點也不慢，只是它的起點比較低一點而已。

擁塞避免

從慢啟動可以看到，cwnd可以很快的增長上來，從而最大程度利用網絡帶寬資源，但是cwnd不能一直這樣無限增長下去，一定需要某個限制。TCP使用了一個叫慢啟動門限(ssthresh)的變量，當cwnd超過該值后，慢啟動過程結束，進入擁塞避免階段。擁塞避免的主要思想是加法增大，也就是cwnd的值不再指數級往上升，開始加法增加。此時當窗口中所有的報文段都被確認時，cwnd的大小加1(此處加1指的是加1個MSS，下文同樣如此)，cwnd的值就隨著RTT開始線性增加，這樣就可以避免增長過快導致網絡擁塞，慢慢的增加調整到網絡的最佳值。

快重傳與快恢復

進入擁塞避免之后，最終還是會碰到擁塞點，發送方此時一直得不到接收端的確認。因此TCP在發送一個數據以后就開啟一個計時器， 在一定時間內如果沒有得到發送數據報的ACK報文，那么就重新發送數據，直到發送成功為止，這就是超時重傳。

而快重傳算法首先要求接收方每收到一個失序的報文段就立即發出重復確認。比如A給B發送M1, M2, M3, M4, M5，如果B收到了M1, M2, M4，M5；M3并沒有接收到，那么在B接到M4時就會發送一次M2的ACK，接到M5，又會發送一次M2的ACK，這樣重復確認M2意在告訴A，M3還沒收到，可能是丟失了。

image.png

當A連續收到了三個確認M2的ACK，若M3超時事件還沒發生，此時A也會假定M3丟失了，這個時候A就不必等待M3設置的計時器到期了，而是進行快速重傳。

而快速恢復是在上述的快速重傳后添加的，快速重傳和快速恢復算法會同時使用，快恢復會：

1.當收到3個重復M2的ACK時，為了預防網絡發生擁塞，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3，重傳M3

快速恢復的思想是“數據包守恒”原則，即同一個時刻在網絡中的數據包數量是恒定的，只有當“老”數據包離開了網絡后，才能向網絡中發送一個“新”的數據包，如果發送方收到一個重復的ACK，那么根據TCP的ACK機制就表明有一個數據包離開了網絡，收到3個重復的ACK，表明有3個“老”的數據包離開了網絡，因此此處加3。

2.再收到重復的ACK時，cwnd增加1。

3.當收到M4（新數據包）的ACK時，把cwnd設置為第一步中的ssthresh的值

通過新數據包的ACK(M4)確認了新的數據，說明從重復ACK時的數據(M3)已收到，該恢復過程結束，可以回到恢復之前的擁塞避免狀態。

四、談談你對Http與Https的關系理解

這道題想考察什么？

1. 是否了解互聯網網絡協議？

考察的知識點

1. Http協議的相關知識
2. Https協議的相關知識

考生應該如何回答

Http協議

HTTP（HyperText Transfer Protocol：超文本傳輸協議）是一種用于分布式、協作式和超媒體信息系統的應用層協議。 簡單來說就是一種發布和接收 HTML 頁面的方法，被用于在 Web 瀏覽器和網站服務器之間傳遞信息。

HTTP 默認工作在 TCP 協議 80 端口，用戶訪問網站 http:// 打頭的都是標準 HTTP 服務。

HTTP 協議以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了Web瀏覽器 和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此，HTTP協議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。

Https協議

HTTPS（Hypertext Transfer Protocol Secure：超文本傳輸安全協議）是一種透過計算機網絡進行安全通信的傳輸協議。HTTPS 經由 HTTP 進行通信，但利用 SSL/TLS 來加密數據包。HTTPS 開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性。

HTTPS 默認工作在 TCP 協議443端口，它的工作流程一般如以下方式：

1、TCP 三次同步握手

2、客戶端驗證服務器數字證書

3、DH 算法協商對稱加密算法的密鑰、hash 算法的密鑰

4、SSL 安全加密隧道協商完成

5、網頁以加密的方式傳輸，用協商的對稱加密算法和密鑰加密，保證數據機密性；用協商的 hash算法進行數據完整性保護，保證數據不被篡改。

加密

HTTPS 解決數據傳輸安全問題的方案就是使用加密算法，具體來說是混合加密算法，也就是對稱加密和非對稱加密的混合使用，這里有必要先了解一下這兩種加密算法的區別和優缺點。

• 對稱加密，顧名思義就是加密和解密都是使用同一個密鑰，常見的對稱加密算法有 DES、3DES 和 AES 等，其優缺點如下：

  優點：算法公開、計算量小、加密速度快、加密效率高，適合加密比較大的數據。

  缺點： 1.交易雙方需要使用相同的密鑰，也就無法避免密鑰的傳輸，而密鑰在傳輸過程中無法保證不被截獲，因此對稱加密的安全性得不到保證。

  2.每對用戶每次使用對稱加密算法時，都需要使用其他人不知道的唯一密鑰，這會使得發收信雙方所擁有的鑰匙數量急劇增長，密鑰管理成為雙方的負擔。對稱加密算法在分布式網絡系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。

• 非對稱加密 非對稱加密算法需要兩個密鑰：公開密鑰（publickey:簡稱公鑰）和私有密鑰（privatekey:簡稱私鑰）。公鑰與私鑰是一對，如果用公鑰對數據進行加密，只有用對應的私鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。 非對稱加密算法實現機密信息交換的基本過程是：甲方生成一對密鑰并將公鑰公開，需要向甲方發送信息的其他角色(乙方)使用該密鑰(甲方的公鑰)對機密信息進行加密后再發送給甲方；甲方再用自己私鑰對加密后的信息進行解密。甲方想要回復乙方時正好相反，使用乙方的公鑰對數據進行加密，同理，乙方使用自己的私鑰來進行解密。

流程

HTTPS 能夠加密信息，以免敏感信息被第三方獲取，所以很多銀行網站或電子郵箱等等安全級別較高的服務都會采用 HTTPS 協議。

1、客戶端發起 HTTPS 請求

用戶在瀏覽器里輸入一個 https 網址，然后連接到 server 的 端口。

2、服務端的配置 采用 HTTPS 協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請，區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl 就是個不錯的選擇，有 1 年的免費服務)。

3、傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。

4、客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。

如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5、傳送加密信息

這部分傳送的是用證書加密后的隨機值，目的就是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

6、服務端解密信息

服務端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內容通過該值進行對稱加密，所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。

7、傳輸加密后的信息

這部分信息是服務段用私鑰加密后的信息，可以在客戶端被還原。

8、客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，于是獲取了解密后的內容，整個過程第三方即使監聽到了數據，也束手無策。

缺點

• 在相同網絡環境中，HTTPS 相比 HTTP 無論是響應時間還是耗電量都有大幅度上升。
• HTTPS 的安全是有范圍的，在黑客攻擊、服務器劫持等情況下幾乎起不到作用。
• 在現有的證書機制下，中間人攻擊依然有可能發生。
• HTTPS 需要更多的服務器資源，也會導致成本的升高。

HTTP 與 HTTPS 區別

• HTTP 明文傳輸，數據都是未加密的，安全性較差，HTTPS（SSL+HTTP） 數據傳輸過程是加密的，安全性較好。
• 使用 HTTPS 協議需要到 CA（Certificate Authority，數字證書認證機構） 申請證書，一般免費證書較少，因而需要一定費用。證書頒發機構如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
• HTTP 頁面響應速度比 HTTPS 快，主要是因為 HTTP 使用 TCP 三次握手建立連接，客戶端和服務器需要交換 3 個包，而 HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是 12 個包。
• http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443。 HTTPS 其實就是建構在 SSL/TLS 之上的 HTTP 協議，所以，要比較 HTTPS 比 HTTP 要更耗費服務器資源。

今天的面試分享到此結束拉~下期在見