計算機網路面試必備（一）
OSI七層協議
OSI全稱為Open System InterConnection，即開放式系統互聯，國際標準化組織ISO制定了OSI模型。該模型按照功能、分工的不同，人為地將網路通訊的工作分成了7層。網際網路的本質就是一系列網路協議。每一層都執行不同的協議，協議就是標準。實際上這個7層是不存在的，區分出這7層的目的就是讓你明白哪一層是幹嘛的！另外，還有人把它劃成四層、五層，具體如下：
對等層之間不能相互直接通訊，各層之間是嚴格單向依賴，上層使用下層提供的服務，下層向上層提供服務。
下面先從最底層的物理層開始介紹：
1.物理層（位元bit）
通過媒介傳輸位元，確定機械及電氣規範。 規定如何為網路通訊實現最底層的物理連線。 如：如何使用電纜和接頭的型別、用來傳送訊號的電壓等。 物理層實際上是一種規定，規定物理媒介裝置在連線網路時的各種規格、引數以及工作方式。 物理媒介（網線，電纜）不屬於物理層，光纖、同軸電纜、雙絞線、
2.資料鏈路層（楨frame）
將位元組裝成幀和點到點的連線。 規定了如何進行實體地址定址，如何在物理線路上進行資料（幀frame）的可靠傳遞以及流量控制，通過使用接收系統的硬體地址或實體地址來定址。 協議有SLIP協議，CSLIP協議，PPP協議等。 交換機工作在資料鏈路層，對幀解碼並根據幀中包含的資訊把資料傳送到正確的接收方。
3.網路層（包package）
網路層也稱通訊子網層，是高層協議之間的介面層，用於控制通訊子網的操作，是通訊子網與資源子網的介面。在計算機網路中進行通訊的兩個計算機之間可能會經過很多個資料鏈路
如果你在談論一個IP地址，那麼你是在處理第3層的問題，這是“資料包”問題，而不是第2層的“幀”。IP是第3層問題的一部分，此外還有一些路由協議和地址解析協議（ARP）。有關路由的一切事情都在第3層處理。地址解析和路由是3層的重要目的。網路層還可以實現擁塞控制、網際互連、資訊包順序控制及網路記賬等功能。
網路層典型裝置：閘道器、路由器
4.傳輸層（段segment）
傳輸層建立在網路層和會話層之間，實質上它是網路體系結構中高低層之間銜接的一個介面層。用一個定址機制來標識一個特定的應用程式（埠號）。傳輸層不僅是一個單獨的結構層，它還是整個分層體系協議的核心，沒有傳輸層整個分層協議就沒有意義。
傳輸層的資料單元是由資料組織成的資料段（segment）這個層負責獲取全部資訊，因此，它必須跟蹤資料單元碎片、亂序到達的資料包和其它在傳輸過程中可能發生的危險。傳輸層為上層提供端到端（終端使用者到終端使用者）的透明的、可靠的資料傳輸服務，所謂透明的傳輸是指在通訊過程中傳輸層對上層遮蔽了通訊傳輸系統的具體細節。
輸層的主要功能是從會話層接收資料，根據需要把資料切成較小的資料片，並把資料傳送給網路層，確保資料片正確到達網路層，從而實現兩層資料的透明傳送。傳輸層是兩臺計算機經過網路進行資料通訊時，第一個端到端的層次，具有緩衝作用。當網路層服務質量不能滿足要求時，它將服務加以提高，以滿足高層的要求；當網路層服務質量較好時，它只用很少的工作。傳輸層還可進行復用，即在一個網路連線上建立多個邏輯連線。
5.會話層（會話協議資料單元SPDU）
在會話層及以上的高層次中，資料傳送的單位不再另外命名，統稱為報文。會話層不參與具體的傳輸，它提供包括訪問驗證和會話管理在內的建立和維護應用之間通訊的機制。如伺服器驗證使用者登入便是由會話層完成的。
會話層提供的服務可使應用建立和維持會話，並能使會話獲得同步。會話層使用校驗點可使通訊會話在通訊失效時從校驗點繼續恢復通訊。這種能力對於傳送大的檔案極為重要。會話層、表示層、應用層構成開放系統的高3層，面對應用程序提供分佈處理，對話管理，資訊表示，恢復最後的差錯等。會話層同樣要擔負應用程序服務要求，而運輸層不能完成的那部分工作，給運輸層功能差距以彌補。主要的功能是對話管理，資料流同步和重新同步。要完成這些功能，需要由大量的服務單元功能組合，已經制定的功能單元已有幾十種。
6.表示層（表示協議資料單元PPDU）
表示層向上對應用層提供服務，向下接收來自會話層的服務。表示層是為在應用過程之間傳送的資訊提供表示方法的服務，它關心的只是發出資訊的語法與語義。表示層要完成某些特定的功能，主要有不同資料編碼格式的轉換，提供資料壓縮、解壓縮服務，對資料進行加密、解密。例如影象格式的顯示，就是由位於表示層的協議來支援。
表示層為應用層提供服務包括語法選擇、語法轉換等。語法選擇是提供一種初始語法和以後修改這種選擇的手段。語法轉換涉及程式碼轉換和字符集的轉換、資料格式的修改以及對資料結構操作的適配。
7.應用層（應用協議資料單元APDU）
網路應用層是通訊使用者之間的視窗，為使用者提供網路管理、檔案傳輸、事務處理等服務。其中包含了若干個獨立的、使用者通用的服務協議模組。網路應用層是OSI的最高層，為網路使用者之間的通訊提供專用的程式。應用層的內容主要取決於使用者的各自需要，這一層設計的主要問題是分佈資料庫、分佈計算技術、網路作業系統和分佈作業系統、遠端檔案傳輸、電子郵件、終端電話及遠端作業登入與控制等。至2011年應用層在國際上沒有完整的標準，是一個範圍很廣的研究領域。在OSI的7個層次中，應用層是最複雜的，所包含的應用層協議也最多，有些還在研究和開發之中。
應用層為作業系統或網路應用程式提供訪問網路服務的介面。
TCP/IP四層模型及原理
TCP/IP協議這個名字是兩個協議的組合，即TCP：Transmission Control Protocol 傳輸控制協議 、 IP： Internet Protocol 網際網路協議，該協議是目前世界上應用最為廣泛的協議，是以TCP和IP為基礎的不同層次上多個協議的集合，兩臺主機要實現通訊，都必須遵守TCP/IP協議。
首先談一下，OSI七層和TCP/IP四層的關係：
①OSI引入了服務、介面、協議、分層的概念，TCP/IP借鑑了OSI的這些概念建立TCP/IP模型。
②OSI先有模型，後有協議，先有標準，後進行實踐；而TCP/IP則相反，先有協議和應用再提出了模型，且是參照的OSI模型。
③OSI是一種理論下的模型，而TCP/IP已被廣泛使用，成為網路互聯事實上的標準。
總結下兩者的異同之處：
相同點：都採用了層次結構的概念；都能夠提供面向連線(TCP協議)和無連線(UDP協議)兩種通訊服務機制。
不同點：
- 對可靠性要求不同，TCP/IP參考模型的要求更高；
- OSI參考模型是在協議開發前設計的，具有通用性；TCP/IP參考模型是在有協議集的情況下建立的，不適用非TCP/IP網路；
- OSI參考模型只是理論上的模型，並沒有成熟的產品支援；而TCP/IP參考模型已經成為“實際上的國際標準”。
TCP/IP與OSI最大的不同在於OSI是一個理論上的網路通訊模型，而TCP/IP則是實際執行的網路協議。
下面分別說說：網路介面層、網路層、傳輸層、應用層1.網路介面層 / 資料鏈路層 / 主機到網路層
實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層——網路互聯層一個訪問介面，以便在其上傳遞IP分組。由於這一層次未被定義，所以其具體的實現方法將隨著網路型別的不同而不同。
作用：(1) 實現網絡卡介面的網路驅動，以處理資料在乙太網線等物理媒介上的傳輸
(2) 網路驅動程式隱藏了不同物理網路的不同電氣特性，為上層協議提供一個統一的介面 。
協議應用：ARP和RARP(Reverse Address Resolve Protocol，逆地址解析協議）實現了IP地址和物理/Mac地址之間的轉換 。
2.網路層 / 網路互聯層
是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網路或主機。同時，為了儘快地傳送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和傳送的順序可能不同，這就需要上層必須對分組進行排序。 網路互連層除了需要完成路由的功能外，也可以完成將不同型別的網路（異構網）互連的任務。除此之外，網路互連層還需要完成擁塞控制的功能。
作用：網路有分區域網(LAN, Local Area Network)和廣域網(WAN, Wide Area Network)。對於後者通常需要使用眾多分級的路由器來連線分散的主機或者LAN，即通訊的兩臺主機一般不是直接連線，而是通過多箇中間節點(路由器)連線的，從而形成網路拓撲連線。(1) 網路層的任務之一就是選擇這些中間節點，以確定兩臺主機間的通訊路徑。 (2) 其次網路層對上層協議隱藏了網路拓撲連線的細節，在使得傳輸層看來通訊雙方是直接連線的
協議應用：
(1) IP協議： IP協議(Internet Protocol)是網路層最核心的協議，它根據資料包的目的IP地址來決定如何投遞該資料包。若資料包不可直接傳送給目標主機，那麼IP協議就為它尋找一個合適的下一跳路由器，並將資料包交付給該路由器去轉發，如此迴圈直至到達目標主機或者傳送失敗而丟棄該資料包。
(2) ICMP協議： ICMP協議(Internet Control Message Protocol，因特網控制報文協議)是IP協議的補充，用於檢測網路的連線狀態，如ping應用程式就是ICMP協議的使用。ICMP包傳送是不可靠的，所以不能依靠接收ICMP包解決網路問題；ICMP與TCP/UDP不同，它們是傳輸層協議，雖然都具有型別域和程式碼域，但是前者和後者不同，ping用到的ICMP協議，不是埠。ICMP協議使用的是IP協議而非使用下層協議提供的的服務，所以嚴格來講它並非網路層協議，而是網路層程式。
3.傳輸層
傳輸層為應用層實體提供端到端的通訊功能，保證了資料包的順序傳送及資料的完整性。
作用：(1) 定義了兩個主要的協議：傳輸控制協議(TCP)、使用者資料報協議(UDP)，其中TCP協議是可靠的、面向連線的協議；UDP協議是不可靠的，面向無連線的協議； (2)確定接收端的埠號即傳送端的埠號，應用程式提供端對端通訊的”錯覺”，即為應用程式隱藏了資料包跳轉的細節，負責資料包的收發、鏈路超時重連等。 協議應用：
(1) TCP協議：(Transmission Control Protocol, 傳輸控制協議) 為應用程式提供可靠的、面向連線的、基於流的服務，具有超時重傳、資料確認等方式來確保資料包被正確傳送到目的端。因此TCP服務是可靠的，使用TCP協議通訊的雙方必須先建立起TCP連線，並在系統核心中為該連線維持一些必要的資料結構，比如連線的狀態，讀寫緩衝區，多個定時器等。當通訊結束時雙方必須關閉連線以釋放這些核心資料。基於流傳送意思是資料是沒有長度限制，它可源源不斷地從通訊的一段流入另一端。 (2) UDP協議： (User Datagram Protocol, 使用者資料報協議) 與TCP協議相反，它為應用程式提供的是不可靠的、無連線的基於資料報的服務。 無連線：通訊雙方不保持一個長久的聯絡，因此應用程式每次傳送資料都要明確指定接收方的地址； 基於資料報的服務：這是相對於資料流而言的，每個UDP資料報都有一個長度，接收端必須以該長度為最小單位將其內容一次性讀出，否則資料將被截斷。UDP不具有傳送時是被重發功能，所以UDP協議在核心實現中無需為應用程式的資料儲存副本，當UDP資料報被成功傳送之後，UDP核心緩衝區中該資料報就被丟棄了
(3)SCTP協議：(Stream Control Transmission Protocol, 流控制傳輸協議)是為了在因特網上傳輸電話訊號而設計的。
4.應用層
TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。應用層面向不同的網路應用引入了不同的應用層協議。其中，有基於TCP協議的，如檔案傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文字連結協議（Hyper Text Transfer Protocol，HTTP），也有基於UDP協議的。
作用：前面所述的三層負責處理網路通訊的相關細節，這部分需要穩定高效，因此它們是在作業系統的核心空間中，而應用層是在使用者空間實現的，負責處理眾多業務邏輯，如檔案傳輸、網路管理。
協議應用：
(1) telne協議：遠端登入協議，它使我們能在本地完成遠端任務
(2) OSPF協議： (Open Shorttest Path First, 開放最短路徑優先) 是一種動態路由更新協議，用於路由器之間的通訊，以告知對方自身的路由資訊 。
(3) DNS協議：(Domain Name Service, 域名服務) 提供機器域名到IP地址的轉換。如百度的域名是www.baidu.com，對應的IP地址是http://119.75.217.109/。DNS協議可以跳過傳輸層直接使用網路層提供的服務，比如ping程式和OSPF協議；也可以既使用TCP服務，又使用UDP服務。（注：ping是應用程式而非協議，它利用網路層的ICMP協議監測網路連線）
TCP、UDP區別
兩者都是傳輸層協議，先簡單的看看他們的區別：
| TCP | UDP |
| 面向連線 | 無連線 |
| 要求系統資源較多 | 要求系統資源較少 |
| 程式結構較複雜 | 程式結構較簡單 |
| 位元組流模式 | 資料報模式 |
| 保證資料正確性、順序 | 可能丟包、不保證順序 |
注：TCP通過檢驗和、序列號、確認應答、重發控制、連線管理以及視窗控制等機制實現可靠性傳輸。TCP一般應用在對可靠性要求比較高的場合，例如http、ftp等等。
UDP的應用場景：RIP選路表的更新、 DNS、SNMP等都是執行在UDP之上。 面向資料報方式、網路資料大多為短訊息、擁有大量Client、對資料安全性無特殊要求、網路負擔非常重，但對響應速度要求高 。
TCP與UDP區別總結：
1、TCP面向連線（如打電話要先撥號建立連線）；UDP是無連線的，即傳送資料之前不需要建立連線。
2、TCP提供可靠的服務。也就是說，通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達；UDP盡最大努力交付，即不保證可靠交付。
3、TCP面向位元組流，實際上是TCP把資料看成一連串無結構的位元組流；UDP是面向報文的。UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等）。
4、每一條TCP連線只能是點到點的；UDP支援一對一，一對多，多對一和多對多的互動通訊。
5、TCP首部開銷20位元組；UDP的首部開銷小，只有8個位元組。
6、TCP的邏輯通訊通道是全雙工的可靠通道；UDP則是不可靠通道。
為什麼UDP有時比TCP更有優勢?
UDP以其簡單、傳輸快的優勢，在越來越多場景下取代了TCP，如實時遊戲。
（1）網速的提升給UDP的穩定性提供可靠網路保障，丟包率很低，如果使用應用層重傳，能夠確保傳輸的可靠性。
（2）TCP為了實現網路通訊的可靠性，使用了複雜的擁塞控制演算法，建立了繁瑣的握手過程，由於TCP內建的系統協議棧中，極難對其進行改進。 採用TCP，一旦發生丟包，TCP會將後續的包快取起來，等前面的包重傳並接收到後再繼續傳送，延時會越來越大，基於UDP對實時性要求較為嚴格的情況下，採用自定義重傳機制，能夠把丟包產生的延遲降到最低，儘量減少網路問題對遊戲性造成影響。
HTTP請求和響應的全過程
HTTP無狀態性：
HTTP協議是無狀態的（stateless）。也就是同一個客戶端在第二次訪問同一個 伺服器上的頁面時，伺服器無法知道這個客戶端曾經訪問過，伺服器也無法分辨客戶端。HTTP無狀態性簡化了伺服器的設計，使伺服器更好的支援大量的併發請求。
HTTP持久連線：
HTTP /1.0採用的是非持久連線，主要缺點是客戶端必須為每一個待請求的物件建立並維護一個新的連線，即每請求一個文件就要有兩倍RTT 的開銷。因為同一個頁面可能存在多個物件，所以非持久連線可能使一個頁面的下載變得十分緩慢，而且這種短連線增加了網路傳輸的負擔。
HTTP /1.1 使用持久連線keep alive，所謂持久連線，就是伺服器在傳送響應後仍然在一段時間內保持這條連線，允許在同一個連線中存在多次資料請求和響應，即在持久連線情況下，伺服器在傳送完響應後並不關閉TCP 連線，而客戶端可以通過這個連線繼續請求其他物件。HTTP/1.1 協議的持久連線有兩種方式：非流水線方式：客戶在收到前一個響應後才能發出下一個請求；流水線方式：客戶在收到HTTP的響應報文之前就能接著傳送新的請求報文。
注：RTT(Round-Trip Time): 往返時延，在計算機網路中它也是一個重要的效能指標，它表示從傳送端傳送資料開始，到傳送端收到來自接收端的確認（接收端收到資料後便立即傳送確認），總共經歷的時延。
HTTP請求與響應全過程：
在使用者在瀏覽器的位址列輸入網址之後：
①瀏覽器根據域名解析地址
瀏覽器根據訪問的域名找到其IP地址。DNS查詢過程如下：
瀏覽器快取：瀏覽器會快取DNS記錄一段時間。 但作業系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不同瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。 系統快取：如果在瀏覽器快取裡沒有找到需要的域名，瀏覽器會做一個系統呼叫（windows裡是gethostbyname），這樣便可獲得系統快取中的記錄。路由器快取：如果系統快取也沒找到需要的域名，則會向路由器傳送查詢請求，它一般會有自己的DNS快取。ISP DNS快取：如果依然沒找到需要的域名，則最後要查的就是ISP快取DNS的伺服器。在這裡一般都能找到相應的快取記錄。
就是將網站名稱轉變成IP地址：localhost-->127.0.0.1，像什麼hosts檔案，DNS域名解析等等可以實現這種功能。域名解析的方式主要有兩種，分別是：
② 瀏覽器與Web伺服器建立一個TCP連線（TCP三次握手）
在客戶機和伺服器之間建立正常的TCP網路連線時：★ 客戶機首先發出一個SYN訊息 ★伺服器使用SYN+ACK應答表示接收到了這個訊息 ★最後客戶機再以ACK訊息響應。 這樣在客戶機和伺服器之間才能建立起可靠的TCP連線，資料才可以在客戶機和伺服器之間傳遞。
拿到域名對應的IP地址之後，User-Agent（一般是指瀏覽器）會以一個隨機埠（1024 < 埠 < 65535）向伺服器的WEB程式（常用的有httpd,nginx等）80埠發起TCP的連線請求。這個連線請求（原始的http請求經過TCP/IP4層模型的層層封包）到達伺服器端後（這中間通過各種路由裝置，區域網內除外），進入到網絡卡，然後是進入到核心的TCP/IP協議棧（用於識別該連線請求，解封包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於核心的模組）的過濾，最終到達WEB程式（本文就以Nginx為例），最終建立了TCP/IP的連線。
③瀏覽器給Web伺服器傳送一個HTTP請求
所謂的HTTP請求，也就是Web客戶端向Web伺服器傳送資訊，這個資訊由如下三部分組成：
●請求行：
例如：GET www.cnblogs.com HTTP/1.1。請求行寫法是固定的，由三部分組成，第一部分是請求方法：（除了常見的只有Get和Post方法，實際上HTTP請求方法還有很多，比如： PUT方法，DELETE方法，HEAD方法，CONNECT方法，TRACE方法），第二部分是請求網址，第三部分是HTTP版本。
●HTTP頭：
HTTP頭在HTTP請求可以是3種HTTP頭：請求頭(request header) 、普通頭(general header)、 實體頭(entity header)。通常來說，由於Get請求往往不包含內容實體，因此也不會有實體頭。
●內容： 只在POST請求中存在，因為GET請求並不包含任何實體。
④伺服器端響應http請求，瀏覽器得到html程式碼
當Web伺服器收到HTTP請求後，會根據請求的資訊做某些處理(這些處理可能僅僅是靜態的返回頁，或是包含Asp.net, PHP, Jsp等語言進行處理後返回)，相應的返回一個HTTP響應。HTTP響應在結構上類似於HTTP請求，也是由三部分組成，分別為：
▲狀態行
例如：HTTP/1.1 200 OK，第一部分是HTTP版本，第二部分是響應狀態碼，第三部分是狀態碼的描述。狀態碼（三位數）分類：資訊類 (100-199)、響應成功 (200-299)、重定向類 (300-399)、客戶端錯誤類 (400-499)、服務端錯誤類 (500-599)。
▲HTTP頭
HTTP響應中包含的頭包括：響應頭(response header)、普通頭(general header)、實體頭(entity header)。
▲返回內容
HTTP響應內容就是HTTP請求所請求的資訊。這個資訊可以是一個HTML，也可以是一個圖片。響應的資料格式通過Content-Type欄位來獲得：Content-Type：image/png；或者我們熟悉的Content-Type：text/html
⑤瀏覽器解析html程式碼，並請求html程式碼中的資源
瞭解持久連線：有時候我們獲取一個HTML頁面，在對瀏覽器對HTML解析的過程中，如果發現額外的URL需要獲取的內容，會再次發起HTTP請求去伺服器獲取，比如樣式檔案，圖片。許多個HTTP請求，只依靠一個TCP連線就夠了，這就是所謂的持久連線。也是所謂的一次HTTP請求完成。
⑥瀏覽器對頁面進行渲染呈現給使用者
HTTP常見響應碼（200、301、302、404、500）
狀態程式碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。
1xx：資訊性狀態碼，表示伺服器已接收了客戶端請求，客戶端可繼續傳送請求。 100：Continue、101：Switching Protocols
2xx：成功狀態碼，表示伺服器已成功接收到請求並進行處理。200：OK 表示客戶端請求成功、204 No Content 成功，但不返回任何實體的主體部分 、206：Partial Content 成功執行了一個範圍（Range）請求。
3xx：重定向狀態碼，表示伺服器要求客戶端重定向。301：Moved Permanently 永久性重定向，響應報文的Location首部應該有該資源的新URL、302：Found 臨時性重定向，響應報文的Location首部給出的URL用來臨時定位資源 、303：See Other 請求的資源存在著另一個URI，客戶端應使用GET方法定向獲取請求的資源、304：Not Modified 客戶端傳送附帶條件的請求（請求首部中包含如If-Modified-Since等指定首部）時，服務端有可能返回304，此時，響應報文中不包含任何報文主體、307 Temporary Redirect 臨時重定向。與302 Found含義一樣。302禁止POST變換為GET，但實際使用時並不一定，307則更多瀏覽器可能會遵循這一標準，但也依賴於瀏覽器具體實現。
4xx：客戶端錯誤狀態碼，表示客戶端的請求有非法內容。400：Bad Request 表示客戶端請求有語法錯誤，不能被伺服器所理解、401：Unauthonzed 表示請求未經授權，該狀態程式碼必須與 WWW-Authenticate 報頭域一起使用、403 Forbidden：表示伺服器收到請求，但是拒絕提供服務，通常會在響應正文中給出不提供服務的原因、404：Not Found 請求的資源不存在，例如，輸入了錯誤的URL。
5xx：伺服器錯誤狀態碼，表示伺服器未能正常處理客戶端的請求而出現意外錯誤。500：Internel Server Error 表示伺服器發生不可預期的錯誤，導致無法完成客戶端的請求、503：Service Unavailable 表示伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常 。
HTTPS和HTTP/2
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。SSL依靠證書來驗證伺服器的身份，併為瀏覽器和伺服器之間的通訊加密。相對HTTP協議來說，HTTPS協議建立資料通道的更加耗時，若直接部署到App中，勢必降低資料傳遞的效率，間接影響使用者體驗。HTTP網站可以訪問HTTPS連結，HTTPS網站無法訪問HTTP連結（除了部分支援mixed-content的瀏覽器）。
HTTPS作為安全協議而誕生，那麼就不得不面對以下兩大安全問題：
-
身份驗證：確保通訊雙方身份的真實性。A希望與B通訊，A如何確認B的身份不是由C偽造的。（由C偽造B的身份與A通訊，稱為中間人攻擊）。
-
通訊加密：通訊的機密性、完整性依賴於演算法與金鑰，通訊雙方是如何選擇演算法與金鑰的。
能同時解決以上兩個問題，就能確保真實有效的通訊雙方採取有效的演算法與金鑰進行通訊，便完成了協議安全的初衷。在介紹HTTPS協議如何解決兩大安全問題前，我們首先了解幾個概念。
-
數字證書：數字證書是網際網路通訊中標識雙方身份資訊的數字檔案，由CA簽發。CA（certification authority）是數字證書的簽發機構。作為權威機構，其稽核申請者身份後簽發數字證書，這樣我們只需要校驗數字證書即可確定對方的真實身份。
-
HTTPS協議、SSL協議、TLS協議、握手協議的關係
HTTPS是Hypertext Transfer Protocol over Secure Socket Layer的縮寫，即HTTP over SSL，可理解為基於SSL的HTTP協議。HTTPS協議安全是由SSL協議（目前常用的，本文基於TLS 1.2進行分析）實現的。SSL協議是一種記錄協議，擴充套件性良好，可以很方便的新增子協議，而握手協議便是SSL協議的一個子協議。TLS協議是SSL協議的後續版本，本篇中涉及的SSL協議預設是TLS協議1.2版本。
HTTPS協議的安全性由SSL協議實現，當前使用的TLS協議1.2版本包含了四個核心子協議：握手協議、金鑰配置切換協議、應用資料協議及報警協議。解決身份驗證與通訊加密的核心，便是握手協議，接下來著重介紹握手協議。
握手協議的作用便是通訊雙方進行身份確認、協商安全連線各引數（加密演算法、金鑰等），確保雙方身份真實並且協商的演算法與金鑰能夠保證通訊安全。對握手協議的介紹限於客戶端對服務端的身份驗證，單向身份驗證也是目前網際網路公司最常見的認證方式。
隨著網際網路的快速發展，HTTP1.x協議得到了迅猛發展，但當App一個頁面包含了數十個請求時，HTTP1.x協議的侷限性便暴露了出來：
- 每個請求與響應需要單獨建立鏈路進行請求(Connection欄位能夠解決部分問題)，浪費資源。
- 每個請求與響應都需要新增完整的頭資訊，應用資料傳輸效率較低。
- 預設沒有進行加密，資料在傳輸過程中容易被監聽與篡改。
HTTP2正是為了解決HTTP1.x暴露出來的問題而誕生的。
說到HTTP2不得不提spdy。 由於HTTP1.x暴露出來的問題，Google設計了全新的名為spdy的新協議。spdy在五層協議棧的TCP層與HTTP層引入了一個新的邏輯層以提高效率。spdy是一箇中間層，對TCP層與HTTP層有很好的相容，不需要修改HTTP層即可改善應用資料傳輸速度。 spdy通過多路複用技術，使客戶端與伺服器只需要保持一條連結即可併發多次資料互動，提高了通訊效率。 而HTTP2便是基於spdy的思路開發的。 通過流與幀概念的引入，繼承了spdy的多路複用，並增加了一些實用特性。
HTTP2為了解決HTTP1.x中頭資訊過大導致效率低下的問題，提出的解決方案便是壓縮頭部資訊。具體的壓縮方式，則引入了HPACK。HPACK壓縮演算法是專門為HTTP2頭部壓縮服務的。為了達到壓縮頭部資訊的目的，HPACK將頭部欄位快取為索引，通過索引ID代表頭部欄位。客戶端與服務端維護索引表，通訊過程中儘可能採用索引進行通訊，收到索引後查詢索引表，才能解析出真正的頭部資訊。HPACK索引表劃分為動態索引表與靜態索引表，動態索引表是HTTP2協議通訊過程中兩端動態維護的索引表，而靜態索引表是硬編碼進協議中的索引表。
HTTP2有什麼特性呢？HTTP2的特性不僅解決了上述已暴露的問題，還有一些功能使HTTP協議更加好用。
- 多路複用（http2為了優化http1.x對TCP效能的浪費。同一域名下的請求，可通過同一條TCP鏈路進行傳輸，使多個請求不必單獨建立鏈路，節省建立鏈路的開銷。）
- 壓縮頭資訊
- 對請求劃分優先順序
- 支援服務端Push訊息到客戶端
此外，HTTP2目前在實際使用中，只用於HTTPS協議場景下，通過握手階段ClientHello與ServerHello的extension欄位協商而來，所以目前HTTP2的使用場景，都是預設安全加密的。
HTTP/2和SPDY的區別: HTTP/2支援HTTP傳輸，SPDY只支援HTTPS； HTTP/2和SPDY的header壓縮演算法不同。
get和Post的區別
在我大全球資訊網世界中，TCP就像汽車，我們用TCP來運輸資料，它很可靠，從來不會發生丟件少件的現象。但是如果路上跑的全是看起來一模一樣的汽車，那這個世界看起來是一團混亂，送急件的汽車可能被前面滿載貨物的汽車攔堵在路上，整個交通系統一定會癱瘓。為了避免這種情況發生，交通規則HTTP誕生了。HTTP給汽車運輸設定了好幾個服務類別，有GET、POST、PUT、 DELETE等等，HTTP規定，當執行GET請求的時候，要給汽車貼上GET的標籤（設定method為GET），而且要求把傳送的資料放在車頂上（url中）以方便記錄。如果是POST請求，就要在車上貼上POST的標籤，並把貨物放在車廂裡。當然，你也可以在GET的時候往車廂內偷偷藏點貨物，但是這是很不光彩；也可以在POST的時候在車頂上也放一些資料，讓人覺得傻乎乎的。HTTP只是個行為準則，而TCP才是GET和POST怎麼實現的基本。
在我大全球資訊網世界中，還有另一個重要的角色：運輸公司。不同的瀏覽器（發起http請求）和伺服器（接受http請求）就是不同的運輸公司。雖然理論上，你可以在車頂上無限的堆貨物（url中無限加引數）。但是運輸公司可不傻，裝貨和卸貨也是有很大成本的，他們會限制單次運輸量來控制風險，資料量太大對瀏覽器和伺服器都是很大負擔。業界不成文的規定是，（大多數）瀏覽器通常都會限制url長度在2K個位元組，而（大多數）伺服器最多處理64K大小的url。超過的部分，恕不處理。如果你用GET服務，在request body偷偷藏了資料，不同伺服器的處理方式也是不同的，有些伺服器會幫你卸貨，讀出資料，有些伺服器直接忽略，所以，雖然GET可以帶request body，也不能保證一定能被接收到哦。
GET和POST還有一個重大區別：對於GET方式的請求，瀏覽器會把http header和data一併傳送出去，伺服器響應200（返回資料）；而對於POST，瀏覽器先發送header，伺服器響應100 continue，瀏覽器再發送data，伺服器響應200 ok（返回資料）。簡言之—— GET產生一個TCP資料包；POST產生兩個TCP資料包。也就是說，GET只需要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和伺服器打個招呼“嗨，我等下要送一批貨來，你們開啟門迎接我”，然後再回頭把貨送過去。因為POST需要兩步，時間上消耗的要多一點，看起來GET比POST更有效。因此Yahoo團隊有推薦用GET替換POST來優化網站效能。但這是一個坑！跳入需謹慎。為什麼？
◆GET與POST都有自己的語義，不能隨便混用。
◆據研究，在網路環境好的情況下，發一次包的時間和發兩次包的時間差別基本可以無視。而在網路環境差的情況下，兩次包的TCP在驗證資料包完整性上，有非常大的優點。
◆並不是所有瀏覽器都會在POST中傳送兩次包，Firefox就只發送一次。
總結一下GET和POST的區別：
get引數通過url傳遞，post放在request body中。
get請求在url中傳遞的引數是有長度限制的，而post沒有。
get比post更不安全，因為引數直接暴露在url中，所以不能用來傳遞敏感資訊。
get請求只能進行url編碼，而post支援多種編碼方式
get請求會瀏覽器主動cache，而post支援多種編碼方式。
get請求引數會被完整保留在瀏覽歷史記錄裡，而post中的引數不會被保留。
- GET和POST本質上就是TCP連結，並無差別。但是由於HTTP的規定和瀏覽器/伺服器的限制，導致他們在應用過程中體現出一些不同。
- GET產生一個TCP資料包；POST產生兩個TCP資料包。
forward和redirect的區別
直接轉發（forward）和間接轉發（redirect）的原理及區別是什麼？
Forward和Redirect代表了兩種請求轉發方式：直接轉發和間接轉發。對應到程式碼裡，分別是RequestDispatcher類的forward()方法和HttpServletRequest類的sendRedirect()方法。 對於間接方式，伺服器端在響應第一次請求的時候，讓瀏覽器再向另外一個URL發出請求，從而達到轉發的目的。它本質上是兩次HTTP請求，對應兩個request物件。 對於直接方式，客戶端瀏覽器只發出一次請求，Servlet把請求轉發給Servlet、HTML、JSP或其它資訊資源，由第2個資訊資源響應該請求，兩個資訊資源共享同一個request物件。
下面從以下四個方面來闡述它倆的區別：
■ 位址列
forward方式為伺服器直接跳轉，客戶端瀏覽器並不知道，位址列內容不變（伺服器內部動作，伺服器請求資源，伺服器直接訪問目標地址的URL，把那個URL的響應內容讀取過來，然後把這些內容再發給瀏覽器。瀏覽器根本不知道伺服器傳送的內容從哪裡來的，所以它的位址列還是原來的地址）；
redirect方式為客戶端瀏覽器根據URL地址，重新向伺服器請求，位址列變（服務端根據邏輯,傳送一個狀態碼,告訴瀏覽器重新去請求那個地址.所以位址列顯示的是新的URL）
■ 資料共享
forward方式轉發頁面和轉發到的頁面可以共享request裡面的資料 ；
redirect方式是全新的request。
■ 運用的地方
forward：使用者登入後根據角色跳轉頁面；
redirect：在使用者登出後跳轉主頁或其他頁面 。
■ 效率：
forward比redirect少了一次伺服器請求，效率高一些。