1、http/1.0、http/1.1和http2.0有什麼區別。

      （1）、http/1.0協議預設使用非持久連線，既在非持久連線下，伺服器處理完客戶端請求後立即斷開TCP連線，伺服器不跟蹤每個客戶，也不記錄過去的請求。
      （2）、http/1.1協議預設使用持久連線，既一個TCP可以傳輸多個WEB物件。同時也可通過配置支援非持久連線。
      （3）、http/1.1增加了Host欄位，因為目前一臺計算機上有多個虛擬主機共享一個IP地址，請求和相應訊息都應該支援Host頭域，且請求訊息中沒有Host頭域會報（400 Bad Request）。此外伺服器應該接受以絕對路徑標記的資源請求。而http/1.0中每臺伺服器都繫結一個唯一的IP，因此，請求訊息中的URL沒有傳遞主機名（hostname）。
      （4）、增加了新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，如果服務因許可權等拒絕請求，就回送相應401（Unauthorized）或403；如果伺服器接受此請求就回送相應嗎100，客戶端就可以繼續傳送帶實體的完成請求。狀態碼的使用，在request在傳送body之前，先發送header試探一下server，如果接受body，再發送body。可以節省頻寬。
      （5）、http/1.0加入了分塊編碼（Chunked TransferCoding）。傳送方將訊息分割成若干個任意大小的資料塊，每個資料塊在傳送時都會附上塊的長度，最後一個零長度的塊作為訊息的結束標誌。這種傳送允許傳送方只快取一個片段，避免快取整個片段帶來的過載。
      （6）、http/1.1在http/1.0的基礎上加入了一些cache的新特性，當快取物件Age超過Expire時變為stale物件，cache不需要直接拋棄stale物件，而是與源伺服器進行重新啟用（revalidation）
      （7）、http/2.0支援多路複用技術，同一個連線併發處理多個請求（NIO），http/1.1可以通過建立多個TCP解決。
      （8）、http/1.1不支援Header資料的壓縮，http/2.0使用HPACK演算法對資料壓縮，降體積提速度。
      （9）、http/2.0請求伺服器，伺服器推送資料時會額外推送客戶需要的資源，客戶下次呼叫不用請求直接呼叫。提升速度。

2、TCP三次握手和四次揮手的流程，為什麼斷開連線要4次,如果握手只有兩次，會出現什麼。

      （1）、TCP三次握手：
                 第一次握手：建立連線時，客戶端傳送syn（Synchronize Sequence Numbers：同步序列編號）包（sny=1）到伺服器，並進入SYN_SEND（請求連線）狀態，等待伺服器確認;
                  第二次握手：伺服器接收到syn包，必須確認客戶的syn（ack=j+1）（ack：確認字元，表示發來的資料已確認接收無誤），同時自己也傳送一個syn包（sny=k），既ack+syn包，此時伺服器進入SYN_RECV（傳送了ACK時的狀態）狀態。
                  第三次握手：客戶端收到服務端傳送的syn+ack包，向服務端傳送確認包ack（sny+1既ack=k+1），此包傳送完畢，客戶端與伺服器進入ESTABLISHED（TCP連線成功）狀態，完成三次握手。
                   
                                                    圖1： TCP三次握手圖
      （2）、TCP四次揮手（連線終止協議，性質為終止協議）：
                   第一次揮手：TCP客戶端傳送一個FIN+ACK+SEQ，用來傳輸關閉客戶端到服務端的資料。進入FIN_WAIT1狀態。
                   第二次揮手：服務端收到FIN，被動傳送一個ACK（SEQ+1）,進入CLOSE_WAIT狀態，客戶端收到服務端傳送的ACK，進入FIN_WAIT2狀態。
                   第三次揮手：伺服器關閉客戶端連線，傳送一個FIN給+ACK+SEQ客戶端。進入LAST_ACK狀態。
                   第四次揮手：客戶端傳送ACK（ACK=SQE序號+1）報文確認，客戶端進入TIME_WAIT狀態，服務端收到ACK進入CLOSE狀態。
                   
                                                                          圖2： TCP四次揮手
      （3）、由於TCP連線時雙工的，因此每個方向都需要單獨進行關閉。這原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個FIN只意味著這一個方向上沒有資料流動，一個TCP連線到一個FIN後仍能傳送資料。首次執行FIN的一方主動關閉，另一方則執行被動關閉。當只握手兩次時，就只會關閉主動發起的一端，另一個仍能傳送資料。

3、TIME_WAIT和CLOSE_WAIT的區別。

      CLOSE_WAIT：等待關閉，是被動關閉連線形成的，也就是第二次揮手時產生的狀態。也就是當對方close一個SOCKET後傳送FIN報文給自己，系統會迴應一個ACK報文給對方，此時進入CLOSE_WAIT狀態。接著，我們需要考慮的事情是檢視是否還有資料傳送給對方，如果沒有就可以close這個連結，傳送FIN給對方，也既關閉連線。所以在CLOSE_WAIT狀態時，需要檢視自己是否需要關閉連線。

      TIME_WAIT：是主動關閉連線方形成的，表示收到了對方的FIN報文，併發送ACK報文，等待2MSL（Maximum Segment Lifetime：報文最大生存時間）約4分鐘時間後進入CLOSE狀態。主要是防止最後一個ACK丟失，由於TIME_WAIT等待時間較長，因此server端儘量減少關閉。

4、為什麼需要TIME_WAIT狀態？

     假設最終的ACK丟失，伺服器將重新發送FIN，客戶端必須維護TCP狀態資訊以便可以重發最終的ACK，否則傳送RST，結果Server認為發生錯誤。TCP實現必須可靠的終止兩端的連線（雙工關閉），Client必須進入TIME_WAIT狀態，因為最總的ACK可能傳送失敗。

5、為什麼TIME_WAIT狀態要保持2MSL這麼長時間？

     如果TIME_WAIT狀態保持時間不足2MSL，第一個連線可以正常關閉，但如果有相同的第二個連接出現，第一個連線的重複報文到達，就會干擾第二個連線。TCP必須防止某個連線的重複報文在連線終止後出現，所以讓TIME_WAIT狀態等待時間大於2MSL，連線響應方向上的TCP報文要麼完全響應完畢，要麼被丟棄。建立二次連線時，就不會混淆。

6、說說你知道的幾種HTTP響應碼。

      ☆ 200 OK：表示客戶端請求成功。
      ☆ 400 Bad Request 語義有誤，不能被當前伺服器理解。
      ☆ 401 Unauthorized 當前請求需要使用者驗證。
      ☆ 403 Forbidden 伺服器收到訊息，但是拒絕提供服務。
      ☆ 404 Not Found 請求資源不存在。
      ☆ 408 Request Timeout 請求超時，客戶端沒有在伺服器預備等待的時間內完成傳送。
      ☆ 500 Internal Server Error 伺服器發生不可預期的錯誤。
      ☆ 503 Server Unavailable 由於臨時的伺服器維護或過載，伺服器當前不能處理請求，此狀況知識臨時的，可恢復。

7、當你用瀏覽器開啟一個連結的時候，計算機做了哪些工作步驟。

     （1）、解析域名。
     （2）、發起TCP的3次握手。
     （3）、建立TCP請求後發起HTTP請求。
     （4）、伺服器相應HTTP請求。
     （5）、瀏覽器得到HTML程式碼，進行解析和處理JSON資料，並請求HTML程式碼中的靜態資源（JS、CSS、圖片等）。
     （6）、瀏覽器對頁面進行渲染。

8、TCP/IP如何保證可靠性，說說TCP頭的結構。

      （1）、三次握手。
      （2）、將資料截斷為合理的長度。應用資料被分割成TCP認為最合適傳送的資料塊。
      （3）、超時重發。
      （4）、對於收到的請求，給予確認響應。
      （5）、校驗出包有錯，丟棄報文段，不響應。
      （6）、對失序資料進行重新排序，傳送於客戶端。
      （7）、能夠丟棄重複資料。
      （8）、流量控制。TCP連線的兩端都有快取大小控制，接收端只允許傳送端傳送自己快取剩餘大小的資料。有效防止快取溢位。
      （9）、擁塞控制。當網路阻塞時，減少資料的傳送。

TCP頭結構：
   （1）、源埠（source port）16位的欄位，定義了傳送這個報文段的主機中的應用程式的埠號。
   （2）、目的埠（destination port）16位的欄位，定義了接收這個報文段的主機中的應用程式的埠號。
   （3）、序列號（sequence number）32位的欄位，定義了指派給本報文段第一個資料位元組的編號。為了保證連線性，要傳送的每一個位元組都要編上號。序號可以告訴終點，報文段中的第一個位元組是這個序列中的哪一個位元組。在建立連線是，雙方使用各自的隨機數生成器生產一個初始序號（inital squence number，ISN），通常兩個方向上的ISN是不同的。
   （4）、確認號（acknowledgment nimber）32位欄位定義了報文段的接收方期望從對方接收的位元組編碼。如果報文段的接收方成功地接收了對方發來的編號為x的位元組，那麼它就返回x+1作為確認號，確認可以和資料捎帶在一起傳送。
   （5）、頭部長度（Hlen）（header length）這個4位元組欄位指出TCP段的頭部長度，以32位欄位來衡量，頭部長度並不規定並可以根據選項欄位中設定的引數面改變。
   （6）、保留（reserved）這個保留欄位佔用6位，它被保留以提供將來使用。
   （7）、URG 緊急資料（urgent data）---這是一條緊急資訊。
   （8）、ACK 確認已收到段
   （9）、PSH 請求在緩衝區尚未填滿時傳送訊息，注意TCP可以等待緩衝區填滿之後再發送段，如果需要立即傳送，應用程式必須利用push引數來通知協議。
   （10）、RST 申請重置連線。
   （11）、SYN 此訊息用於在建立連線時同步傳輸資料的計時器。
   （12）、FIN 該屬性申明發送端已經發送出被傳輸資料的最後一個位元組。
   （13）、視窗大小（window）16位欄位，這個欄位定義的是傳送TCP的視窗大小，以位元組為單位。視窗最大長度是65535位元組，這個值通常被稱為接收視窗（rwnd）,並由接收方來決定。這種情況下，傳送方必須服從接收方的指示。
   （14）、校驗和（checksum）16位欄位包含的是檢驗和，檢驗和是差錯控制的手段之一。
   （15）、緊急指標（urgent point）該欄位佔用2位元組，與URG程式碼位一起使用並且申明及時使存在著緩衝區溢位也必須緊急接收的資料末端。因此，如果有些資料需要不按照順序被送往目的應用程式，那麼傳送端的應用程式必須利用緊急資料引數通知TCP。
   （16）、選項（option）該欄位為變長且可以忽略。他的最大長度為3位元組，用於解決一些輔助任務----比如，選擇最大段長。選項可以位於TCP頭部的末端，其長度必須是8的倍數。
   （17）、填充（padding）該欄位長度不固定，這是個用於補充頭部欄位使得它的長度為32位字的整數倍的一個偽欄位9

9、如何理解HTTP協議的無狀態性。

       HTTP協議是無狀態的，指的是HTTP協議對於事務處理沒有記憶功能，伺服器不知道客戶端是什麼狀態。相當於，開啟一個伺服器上的網頁與上一次開啟這個伺服器上的網頁之間沒有任何聯絡。HTTP是一個無狀態的面向連線的協議，無狀態不代表HTTP不能保持TCP連線，更不代表HTTP使用的是UDP協議（無連線）。

10、簡述Http請求get和post的區別以及資料包格式。

    ▶ GET請求可被快取，POST請求不能被快取。
    ▶ GET請求被保留著瀏覽器歷史記錄中，POST請求不會被保留。
    ▶ GET請求能被收藏至書籤中，POST請求不能被收藏至書籤。
    ▶ GET請求不應在處理敏感資料時使用，POST可以使用者處理敏感資料。
    ▶ GET請求有長度限制，POST請求沒有長度限制。
    ▶POST不限制提交的資料型別，所以POST可以提交檔案到伺服器。
    資料包格式 == TCP頭結構

11、HTTP有哪些method。

      ★ GET：獲取資源。
      ★ POST：表單提交。
      ★ HEAD：獲取報頭資訊，HEAD 方法與 GET 方法類似，但並不會返回響應主體。
      ★ PUT 與PATCH：更新資源，PUT 對後臺來說 PUT 方法的引數是一個完整的資源物件，它包含了物件的所有欄位，PATCH 對後臺來說 PATCH 方法的引數只包含我們需要修改的資源物件的欄位。
      ★ DELETE：刪除資源。
      ★ OPTIONS：獲取目標資源所支援的通訊選項,使用 OPTIONS 方法對伺服器發起請求,以檢測伺服器支援哪些 HTTP 方法。

12、簡述HTTP請求的報文格式。

        客戶端與服務端通訊時傳輸的內容我們稱之為報文。
        客戶端傳送給伺服器的稱為”請求報文“，伺服器傳送給客戶端的稱為”響應報文“。
         
                                                                        圖3 POST請求 報文格式
    
                                                                        圖4  GET請求 報文格式

                                                                             圖5 報文響應格式

13、HTTP的長連線是什麼意思。

       長連線是指客戶端與服務端建立連線後，不會因完成了一次請求後，它們之間的連線主動關閉。後續的讀寫操作會繼續使用這個連結。 如果一個連線兩小時內都沒有任何動作，伺服器會向客戶端傳送一個探測報文段、根據客戶端主機相應探測4個客戶端狀態，①、客戶端正常時，且伺服器可達。此時客戶端TCP響應正常，伺服器將定時器復位。②、客戶端已經崩潰，並且關閉或正在重啟，客戶端不能響應TCP，伺服器將無法收到客戶端對探測器的響應。伺服器總共傳送10個這樣的探測，每間隔75秒。如伺服器沒有收到任何響應，他就認為客戶端已經關閉並終止連線。③、客戶端崩潰，但已重啟。伺服器將對其保持探測響應，這個響應是一個復位，使得伺服器終止這個連線。④、 客戶機正常執行，但是伺服器不可達。這種與②類。
       由上可以看出，長連線可以省去較多的TCP建立和關閉操作，減少浪費，節約時間。對於頻繁請求資源的客戶端適合使用長連線。在長連線的應用場景下，client端一般不會主動關閉連線，當client與server之間的連線一直不關閉，隨著客戶端連線越來越多，server會保持過多連線。這時候server端需要採取一些策略，如關閉一些長時間沒有請求發生的連線，這樣可以避免一些惡意連線導致server端服務受損；如果條件允許則可以限制每個客戶端的最大長連線數，這樣可以完全避免惡意的客戶端拖垮整體後端服務，例如：資料庫的連線用長連線。

14、HTTPS的加密方式是什麼，講講整個加密解密流程。

 加密方式： 1）、對稱密碼演算法：指加密和解密使用相同的金鑰，速度高，可加密內容較大，用來加密會話過程中的訊息。典型演算法DES、AES、RC5、IDEA（分組加密）RC4。
                    2）、非對稱密碼演算法：又稱為公鑰加密演算法，是指加密和解密使用不同的金鑰，加密速度較慢，但能提供更好的身份認證技術，用來加密對稱加密的金鑰（公開的金鑰用於加密，私有的金鑰用於解密）典型的演算法RSA、DSA、DH。
                   3）、雜湊演算法：將檔案內容通過此演算法加密變成固定長度的值（雜湊值），這個過程可以使用金鑰也可以不使用。這種雜湊變化是不可逆的，也就是說不能從雜湊值程式設計原文，因此雜湊變化通道常用語驗證原文是否被篡改。典型的演算法MD5、SHA、BASE64、CRC等。
注意：SSL協議在建立鏈路時，SSL首先對對稱加密的金鑰進行對公加密，鏈路建立好之後，SSL對傳輸內容使用對稱加密。

 SSL加密過程：參考15問題圖7 雙向認證：  單向認證作為了解加密過程簡化流程。

                                                          圖6  單向認證
   第三步：客戶端使用服務端返回的資訊驗證伺服器的合法性，包括：
                 1）、證書是否過期。
                 2）、釋出伺服器證書的CA是否可靠。
                 3）、返回的公鑰是否能正確解開返回證書中的數字簽名。
                 4）、伺服器證書上的域名是否和伺服器實際域名相匹配。

15、Http和Https的三次握手有什麼區別。

       題目2中所說的握手為HTTP握手的流程，Https在Http的基礎上加入了SSL/TSL協議，SSL依靠證書來驗證伺服器的身份，併為伺服器與瀏覽器之間的通訊加密。下圖為HTTPS的握手流程。
       
                                                             圖7 雙向認證

16、什麼是分塊傳送。

       （1）、分塊傳送是超文字協議HTTP中的一種傳輸機制，允許HTTP由網頁伺服器傳送給客戶端應用（通常是網頁瀏覽器）的資料可以分成多個部分。分塊傳送只在HTTP/1.1中提供。HTTP應答訊息中傳送的資料是整個傳送的，Content-Length訊息頭欄位表示資料的長度。資料的長度很重要，因為客戶端需要知道哪裡是應答訊息的結束，以及後續應答訊息的開始。然而，使用分塊傳輸編碼，資料分解成一系列資料塊，並以一個或多個塊傳送，這樣伺服器可以傳送資料而不需要預先知道傳送內容的總大小。通常資料塊的大小是一致的，但也不總是這種情況。
       （2）、對於在傳送HTTP頭部前，無法計算出Content-Length的HTTP請求及回覆（例如WEB服務端產生的動態內容），可以使用分塊傳輸，使得不至於等待所有資料產生後，再發送帶有Content-Length的HTTP頭部，而是將已經產生的資料一塊一塊傳送出去。
        （3）、HTTP BODY資料成連續的塊傳輸，每塊資料的最開始處，指明瞭該資料塊的大小，隨後則是CRLF，資料，及結尾CRLF。可見每塊資料都是包含在兩個CRLF之間，最後一塊資料則是0CRLFCRLF，兩個CRLF之間沒有任何資料；資料大小以16進位制字串表示（不是二進位制）。
        （4）、客戶端傳送請求時，也可以使用分塊傳輸，但是一般客戶端傳送請求前，不知道服務端是否支援分塊傳輸，所以，客戶端可以傳送HTTP頭部，表明使用分塊傳輸，假如服務端不支援，將會回覆 411(Length Required) 錯誤，中斷請求。

17、Session和cookie的區別。

       （1）、Cookie儲存在客戶端，未設定儲存時間的Cookie，關閉瀏覽器會話Cookie就會被刪除；設定了儲存時間的Cookie儲存在使用者裝置的磁碟中知道過期，同時Cookie在客戶端所以可以偽造，不是十分安全，敏感資料不易儲存。Session儲存在伺服器端，儲存在IIS的程序開闢的記憶體中，而Session過多會消耗伺服器資源，所以儘量少使用Session。
       （2）、Session是伺服器用來跟蹤使用者的一種手段，每個Session都有一個唯一標識：session ID。當服務端生成一個Session時就會向客戶端傳送一個Cookie儲存到客戶端，這個Cookie儲存的是Session的SessionId這樣才能保證客戶端發起請求後，使用者能夠與伺服器端成千上萬的Session進行匹配，同時也保證了不同頁面之間傳值的正確性.
       （3）、儲存資料型別不同：Session能夠儲存任意的JAVA物件，Cookie只能儲存String型別的物件。
       （4）、長於10K的資料，不要用到Cookies。

18、DNS使用的協議（既使用TCP也是用UDP）？

       1）、首先了解一下TCP與UDP傳送位元組的長度限制：
               UDP報文的最大長度為512位元組，而TCP則允許報文長度超過512位元組。當DNS查詢超過512位元組時，協議的TC標誌出現刪除標誌，這時則使用TCP傳送。通常傳統的UDP報文一般不會大於512位元組。
       2）、區域傳送時使用TCP，主要有一下兩點考慮：
               輔域名伺服器會定時（一般3小時）向主域名伺服器進行查詢以便了解資料是否有變動。如有變動，則會執行一次區域傳送，進行資料同步。區域傳送將使用TCP而不是UDP，因為資料同步傳送的資料量比一個請求和應答的資料量要多得多。
TCP是一種可靠的連線，保證了資料的準確性。
       3）、域名解析時使用UDP協議：
              客戶端向DNS伺服器查詢域名，一般返回的內容都不超過512位元組，用UDP傳輸即可。不用經過TCP三次握手，這樣DNS伺服器負載更低，響應更快。雖然從理論上說，客戶端也可以指定向DNS伺服器查詢的時候使用TCP，但事實上，很多DNS伺服器進行配置的時候，僅支援UDP查詢包。

19、TCP粘包和拆包產生的原因

       ①、應用程式寫入資料的位元組大小大於套接字傳送緩衝區的大小。
       ②、進行MSS大小的TCP分段。MSS是最大報文段長度的縮寫。MSS是TCP報文段中的資料欄位的最大長度。資料欄位加上TCP首部才等於整個的TCP報文段。所以MSS並不是TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度
       ③、乙太網的payload大於MTU進行IP分片。MTU指：一種通訊協議的某一層上面所能通過的最大資料包大小。如果IP層有一個數據包要傳，而且資料的長度比鏈路層的MTU大，那麼IP層就會進行分片，把資料包分成託乾片，讓每一片都不超過MTU。注意，IP分片可以發生在原始傳送端主機上，也可以發生在中間路由器上。

解決辦法：¤  訊息定長。例如100位元組。
                  ¤  在包尾部增加回車或者空格符等特殊字元進行分割，典型的如FTP協議
                  ¤  將訊息分為訊息頭和訊息尾。
                  ¤  其它複雜的協議，如RTMP協議等。
--------------------- 
作者：鄭先生@樊小姐 
來源：CSDN 
原文：https://blog.csdn.net/zhengzhaoyang122/article/details/82184072 
版權宣告：本文為博主原創文章，轉載請附上博文連結！