http和https的區別

（1）http是http協議運行在tcp之上，所傳輸的內容都是明文，客戶端和伺服器端都無法驗證對方的身份。

（2）https是http協議運行在SSL/TLS之上，SSL/TLS運行在tcp之上。所有傳輸的內容都經過加密。加密採用對稱加密，但對稱加密的祕鑰用伺服器方的證書進行非對稱加密，此外客戶端可以驗證伺服器端的身份，如果配置了客戶端驗證，伺服器方也可以驗證客戶端的身份。

（3）https協議需要到CA申請證書，一般免費證書很少，需要繳費;

（4）http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的SSL加密傳輸協議;

（5）http和https使用的是完全不同的鏈接方式，所用的埠也不一樣，前者是80，後者是443;

（6）http的鏈接很簡單，是無狀態的。

從輸入網址到獲得網頁的過程

（1）查詢DNS,獲取域名對應的ip地址； 1）瀏覽器搜索自身的DNS緩存； 2）搜索操作系統的DNS緩存； 3）讀取本地的HOST文件； 4）發起一個DNS系統調用； A、寬頻運營伺服器查看本身緩存； B、運營商伺服器發起一個迭代DNS解析請求；

（2）瀏覽器獲得域名對應的ip地址後，發起HTTP三次握手；

（3）TCP/IP鏈接建立起來後，瀏覽器就可以向伺服器發送HTTP請求;

（4）伺服器接收到這個請求，根據路徑參數，經過後端的一些處理生成html頁面代碼返回給瀏覽器;

（5）瀏覽器拿到完整的html頁面代碼開始解析和渲染，如果遇到引用外部的js,css，圖片等靜態資源，它們同樣也是一個個的http請求，都需要經過上面的步驟。

TCP如何保證可靠傳輸？三次握手過程？四次揮手過程？

TCP如何保證可靠傳輸

（1）數據報校驗; （2）超時重傳機制; （3）應答機制; （4）對失序數據包重排序; （5）TCP還能提供流量控制;

TCP是什麼：（通信協議） 是一種面向連接、可靠、基於位元組流的傳輸層通信協議。

TCP的組成部分： 特別要注意的信息： ACK:TCP協議規定，只有ACK=1時有效，也就是連接建立後所有發送的報文ACK必須為1;

SYN:在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。若對方同意建立連接，則響應的報文中使SYN=1和ACK=1.（SYN置1表示這是一個連接請求或連接接受報文）

FIN(finish)表示終結的意思，用來釋放一個連接。當FIN=1時，表明此報文段的發送數據已經發送完畢，並要求釋放連接。

序號：佔4位元組，範圍（0，232-1）,共232個序號。序號增加到232-1後，下一個序號就又回到0（採用取模運算）。TCP是面向位元組流的，傳輸的位元組流每一個位元組都按照順序編號，且必須在連接建立時設置，首部中的序號欄位指本報文段所發送的數據第一個位元組的序號。

例如：一報文段的序號欄位值是301，而攜帶的數據共有100位元組，表明第一個位元組序號是301，最後一個位元組序號是400.下一個報文段的數據序號從401開始，這個301、401叫做報文段序號。

三次握手的過程

第一次握手：首先由Client發出請求連接即SYN=1，ACK=0(TCP規定SYN=1時不能攜帶數據，但要消耗一個序列號)，因此聲明自己的序號是seq=x;

第二次握手：然後Server一直監聽客戶端是否發來請求，監聽到客戶端有請求發送，核對後進行回復確認，即SYN=1，ACK=1，seq=y, ack=x+1;

第三次握手：然後Client再依次進行確認，但不用SYN,這時即為ACK=1，seq=x+1, ack=y+1. 然後就建立連接;

問題：為什麼進行三次握手，兩次確認，兩次握手，一次確認不行麼？ 問題的根源在於防止已失效的鏈接請求報文段又傳送到server，產生錯誤。

什麼是「已失效的鏈接請求報文段」

考慮一種正常的情況:A發出鏈接請求，但因鏈接請求報文丟失而未收到確認（可能網路阻塞、斷網、斷電等）。於是A再重傳一次鏈接請求，後來收到確認（網路環境變好了），建立了鏈接。數據傳輸完畢後，就釋放了鏈接。A共發送兩個鏈接請求報文段，其中第一個丟失，第二個到達了B。沒有「已失效的鏈接請求。

現假定一種異常情況，A發送的第一個鏈接請求報文段並沒有丟失，而在某些網路結點長時間滯留，以致延誤到鏈接釋放以後的某個時間纔到達B。本來這是一個早已失效的報文段，但B收到此失效的鏈接請求報文段後，就誤認為是A又發出一次新的鏈接請求。於是向A發出確認報文段，同意建立連接。假設不採用三次握手，那麼只要B發出確認，新的鏈接就建立。

由於現在A並沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻以為新的運輸鏈接已經建立了，並一直等待A發來數據。從而造成B的許多資源白白浪費。

採用三次握手的辦法就可以防止上述現象的發生。例如在剛才的情況下，A不會向B的確認發出確認，B由於收不到確認，就知道A並沒有要求建立連接。

釋放連接的過程：

要理解四次揮手的過程，客戶端A沒有東西發送時，就會請求釋放連接，發送一個FIN包（沒有數據），此時客戶端狀態變成FIN_WAIT_1(A不能發數據，但可以接受數據)，服務端B接受到A那邊的鏈接已經關閉。B會發送一個確認的包ACK,A收到B的確認後進入FIN_WAIT_2等待狀態，等待B釋放連接，此時B把要發的數據發給A，發完並向A請求釋放連接FIN=1，A收到後回復一個確認消息ACK=1，並進入Time_wait狀態，等待2msl.

為什麼等待？

假設A回復的確認信息一發送，就斷開連接，而這個確認信息在發送的過程中丟失，B在規定時間內沒有收到確認，就會重傳。若A有time_wait，就會再次確認信息發送。不然會出現異常關閉。

另外B存在一個保活狀態，即使A突然故障死機，那B那邊的鏈接資源什麼時候釋放呢？就是保活時間到了後，B會發送探測信息，以決定是否釋放連接。

Get和Post的區別

（1）瀏覽器對url的長度有限制，所以get請求不能代替post請求發送大量數據（get傳送數據少，post的傳輸數據大）；

（2）get請求不安全（傳輸過程中是明文的）（post是安全的）；

（3）get請求是冪等的（多個請求返回同一個結果）（感覺像緩存似的)；

（4）post請求不能被緩存；

在以下情況中，請使用post請求：

1、無法使用緩存文件（更新伺服器上的文件或資料庫）;

2、向伺服器發送大量數據（post沒有數據量限制）;

3、發送包含未知字元的用戶輸入時，post比get更穩定也更可靠;

TCP和UDP區別？如何改進TCP

（1） UDP是無連接，即發送數據之前不需要建立連接；

（2）UDP使用盡最大努力交付，即不保證可靠交付，同時也不能使用擁塞控制；

（3）UDP是面向報文，UDP沒有擁塞控制，很適合多媒體通信要求；

（4）UDP支持一對一，一對多，多對一和多對多的交互通信；

（5）UDP的首部開銷小，只有8個位元組；

（6）TCP是面向連接的運輸層協議；

（7）每一條TCP連接只能有兩個端點，每一條TCP連接只能是點對點（一對一）；

（8）TCP提供可靠交付的服務；

（9）TCP提供全雙工通道 （html5 websocket就是採用全雙工通道）；

（10）TCP是面向位元組流的；

（11）首部最低20個位元組；

推薦閱讀：