計算機網絡與HTTP面試常見知識點彙總

時間 2019-12-04

原文原文鏈接

本人方向爲前端，從八月份準備到九月份面試到十月份拿到滿意的offer，前先後後大概兩個月，期間面試了不少互聯網公司，在面試中發現基礎佔了80%，項目和其餘佔了20%，如今面試結束了，想系統的把前端常見的面試問題整理一下，主要分爲計算機網絡與HTTP，HTML5，CSS3，算法，其餘面試遇到的問題這幾個類別，方便本身之後查閱複習也能夠給別人參考，尚未寫完，目前正在補充中，地址： https://github.com/wangfengyu...

1、計算機網絡

1. 概述

1.1 TCP/IP分層

TCP/IP是一個協議族，是一組不一樣層次上的多個協議的組合，一般可分爲4層協議系統，每組負責不一樣的功能html

鏈路層：也稱數據鏈路層或網絡接口層，用於處理與電纜（或其餘任何傳輸媒介）的物理接口細節；

數據鏈路層中的主要協議有點對點協議PPP,CSMA/CD協議,以太網802.3前端

網絡層：網絡層向上只提供簡單靈活的、無鏈接的、盡最大努力交付的數據報服務。網絡層不提供服務質量的承諾,即所傳輸的分組可能出錯、丟失、重複和失序,固然也不保證分組交付的時限。
網際層中主要協議有IP協議,地址解析協議ARP和網際控制報文協議ICMP等。git

IP協議是網際層的核心,經過路由選擇將下一跳IP封裝後交給網絡接口層。IP 數據報是無鏈接服務。
ICMP是網際層的補充,能夠回送報文。用來檢測網絡是否通暢(使用ping命令)。
ARP是經過已知IP,尋找對於主機的MAC地址。github

傳輸層：主要爲兩臺主機身上的應用程序提供端到端的通訊；TCP（傳輸控制協議）和UDP（用戶數據包協議）
二者的區別以下：web
1. TCP提供面向鏈接的、可靠的數據流傳輸，而UDP提供的是非面向鏈接的、不可靠的數據流傳輸
2. TCP傳輸單位稱爲TCP報文段，UDP傳輸單位稱爲用戶數據報。
3. TCP注重數據安全性，UDP數據傳輸快，由於不須要鏈接等待，少了許多操做，可是其安全性卻通常。
應用層：負責處理特定的應用程序細節；
應用層中主要協議有域名系統DNS,文件傳輸協議FTP,遠程終端協議TELNET,超文本傳輸協議HTTP,簡單郵件傳送協議SMTP,郵件讀取協議POP3和IMAP,動態主機配置協議DHCP等。
DNS：提供域名解析服務,提供域名到IP地址之間的轉換,使用端口53
FTP：在異構網絡中任意計算機之間傳送文件,使用端口21
TELNET：提供用戶遠程登陸服務,使用端口23,使用明碼傳送,保密性差、簡單方便
HTTP：用於實現萬維網上的各類連接,即萬維網客戶程序與萬維網服務器之間的鏈接,使用端口80
SMTP/POP三、IMAP：提供郵件的傳輸,用來控制信件的發送、中轉、從郵件服務器讀取郵件
DHCP：爲新加入網絡的計算機自動分配IP地址

OSI參考模型分層：
面試

模型把網絡通訊的工做分爲7層。1至4層被認爲是低層，這些層與數據移動密切相關。5至7層是高層，包含應用程序級的數據。每一層負責一項具體的工做，而後把數據傳送到下一層。由低到高具體分爲：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。算法

每一層的功能和協議有：json

物理層：經過媒介傳輸比特,肯定機械及電氣規範（比特Bit）；RJ4五、CLOCK、IEEE802.3 （中繼器，集線器，網關）
數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）；PPP、FR、HDLC、VLAN、MAC （網橋，交換機）
網絡層：負責數據包從源到宿的傳遞和網際互連（包Packet）；IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、（路由器）
傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）；TCP、UDP、SPX
會話層：創建、管理和終止會話（會話協議數據單元SPDU）；NFS、SQL、NETBIOS、RPC
表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）；JPEG、MPEG、ASII
應用層：容許訪問OSI環境的手段（應用協議數據單元APDU）；FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

1.2 電路交換、報文交換與分組交換

(1) 電路交換的三個過程
電路創建 -> 數據傳輸 -> 電路拆除
在通訊以前要在通訊雙方之間創建一條被雙方獨佔的物理通路(由通訊雙方之間的交換設備和鏈路逐段鏈接而成)
(2) 報文交換
報文交換方式的數據傳輸單位是報文,報文就是站點一次性要發送的數據塊,其長度不限且可變。當一個站要發送報文時,它將一個目的地址附加到報文上,網絡節點根據報文上的目的地址信息,把報文發送到下一個節點,一直逐個節點地轉送到目的節點。
每一個節點在收到整個報文並檢查無誤後,就暫存這個報文, 而後利用路由信息找出下一個節點的地址, 再把整個報文傳送給下一個節點。所以,端與端之間無需先經過呼叫創建鏈接。
(3) 分組交換
分組交換是報文交換的一種改進,它將報文分紅若干個分組,每一個分組的長度有一個上限,有限長度的分組使得每一個節點所需的存儲能力下降了,分組能夠存儲到內存中,提升了交換速度。它適用於交互式通訊,如終端與主機通訊。瀏覽器

1.3 封裝

當應用程序用TCP傳送數據時，數據被送入協議棧中，而後逐個經過每一層直到被看成一串比特流送入網絡。其中每一層對收到的數據都要增長一些首部信息（有時還要增長尾部信息），該過程下圖所示。TCP傳給IP的數據單元稱做 TCP報文段或簡稱爲TCP段。IP傳給網絡接口層的數據單元稱做 IP數據報(IP datagram)。經過以太網傳輸的比特流稱做幀(Frame)。
緩存

1.4 端口號

TCP對應的協議：
（1） FTP：定義了文件傳輸協議，使用21端口。
（2） Telnet：一種用於遠程登錄的端口，使用23端口，用戶能夠以本身的身份遠程鏈接到計算機上，可提供基於DOS模式下的通訊服務。
（3） SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。
（4） POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。
（5）HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。
UDP對應的協議：
（1） DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。
（2） SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。
（3） TFTP(Trival File Transfer Protocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。

2. 鏈路層

在 TCP/IP協議族中，鏈路層主要有三個目的:

IP模塊發送和接收IP數據報；
爲ARP模塊發送ARP請求和接收ARP應答；
爲RARP發送RARP請求和接收RARP應答。TCP/IP支持多種不一樣的鏈路層協議，這取決於網絡所使用的硬件。
2.1 基本概念
以太網和802.3對數據幀的長度都有一個限制，其最大值分別是1500和1492字節。鏈路層的這個特性稱做MTU，最大傳輸單元。不一樣類型的網絡大多數都有一個上限。
當在同一個網絡上的兩臺主機互相進行通訊時，該網絡的MTU是很是重要的。可是若是兩臺主機之間的通訊要經過多個網絡，那麼每一個網絡的鏈路層就可能有不一樣的MTU。重要的不是兩臺主機所在網絡的MTU的值，重要的是兩臺通訊主機路徑中的最小MTU。它被稱做路徑MTU。
兩臺主機之間的路徑 MTU不必定是個常數。它取決於當時所選擇的路由。而選路不必定是對稱的（從A到B的路由可能與從B到A的路由不一樣），所以路徑MTU在兩個方向上不必定是一致的。

3. 網絡層

3.1 IP協議

IP是TCP/IP協議族中最爲核心的協議，全部的TCP、UDP、ICMP及IGMP數據都以IP數據報格式傳輸。IP提供不可靠、無鏈接的數據報傳輸服務。不可靠是指它不能保證IP數據報能成功地到達目的地，僅提供最好的傳輸服務。無鏈接是IP並不維護任何關於後續數據報的狀態信息。

3.1.1 IP地址分類

互聯網上的每一個接口必須有一個惟一的Internet地址（也稱做IP地址）。IP地址長 32 bit。Internet地址並不採用平面形式的地址空間，如一、二、 3等。IP地址具備必定的結構，五類不一樣的互聯網地址格式如圖所示

A類地址：以0開頭，第一個字節範圍：0~127（1.0.0.0 - 126.255.255.255；
B類地址：以10開頭，第一個字節範圍：128~191（128.0.0.0 - 191.255.255.255；
C類地址：以110開頭，第一個字節範圍：192~223（192.0.0.0 - 223.255.255.255；
10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。（Internet上保留地址用於內部）

IP地址與子網掩碼相與獲得主機號
迴環地址：
主要做用有兩個：一是測試本機的網絡配置，能PING通127.0.0.1說明本機的網卡和IP協議安裝都沒有問題；另外一個做用是某些SERVER/CLIENT的應用程序在運行時需調用服務器上的資源，通常要指定SERVER的IP地址，但當該程序要在同一臺機器上運行而沒有別的SERVER時就能夠把SERVER的資源裝在本機，SERVER的IP地址設爲127.0.0.1一樣也能夠運行。
本地迴環地址指的是以127開頭的地址（127.0.0.1 - 127.255.255.254），一般用127.0.0.1來表示。

3.2 ARP協議

ARP協議的用途：解決同一個局域網內主機或路由器的IP地址和MAC地址的映射問題。
如今源端計算機 A ( 192.168.3.1 )要和計算機 B(192.168.3.2)通訊。在計算機 A 發送信息前, 必須首先獲得計算機B的MAC地址的映射關係。

ARP 協議工做過程以下:

主機 A 首先查看本身的高速緩存中的 ARP緩存表,看其中是否有與 192.168.3.2 對應的 ARP 表項。若是找到,則直接利用該 ARP 表項中的 MAC 值把 IP 數據包封裝成幀發送給主機B。
若是在 ARP 表中找不到對應的地址項,則建立一個 ARP 請求數據包,並以廣播方式發送(把以太幀的目的地址設置爲 FF-FF-FF-FF-FF-FF) 。包中有須要查詢的目的計算機的 IP 地址(192.168.3.2) , 以及主機 A 本身的 IP 地址和 MAC 地址。
包括計算機 B 在內的屬於 192.168.3.0 網絡上的全部計算機都收到 A 的 ARP 請求包,而後將計算機 A 的 IP 地址與 MAC 地址的映射關係存入各自的 ARP 表中。
計算機 B 建立一個 ARP 響應包,在包中填入本身的 MAC 地址,以單播方式直接發送給主機 A。
主機 A 收到響應後, 從包中提取出所需查詢的IP地址及其對應的MAC地址, 添加到本身的 ARP 表中。並根據該 MAC 地址將所須要發送的數據包封裝成幀發送出去。

注意:
(1)ARP 表的內容是按期更新的,若是一條 ARP 表項好久沒有使用了,則它將被從 ARP 表中刪除。
(2)若是所要找的主機和源主機不在同一個局域網上, 那麼就要經過ARP找到一個位於本局域網上的某個路由器的硬件地址, 而後把分組發送給這個路由器, 讓這個路由器把分組轉發給下一個網絡, 剩下的工做就由下一個網絡來作.

3.3 RARP協議

反向地址轉換協議就是將局域網中某個主機的物理地址轉換爲IP地址，好比局域網中有一臺主機只知道物理地址而不知道IP地址，那麼能夠經過RARP協議發出徵求自身IP地址的廣播請求，而後由RARP服務器負責回答。

工做原理：

給主機發送一個本地的RARP廣播，在此廣播包中，聲明本身的MAC地址而且請求任何收到此請求的RARP服務器分配一個IP地址；
本地網段上的RARP服務器收到此請求後，檢查其RARP列表，查找該MAC地址對應的IP地址；
若是存在，RARP服務器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用；
若是不存在，RARP服務器對此不作任何的響應；
源主機收到從RARP服務器的響應信息，就利用獲得的IP地址進行通信；若是一直沒有收到RARP服務器的響應信息，表示初始化失敗。

3.4 ICMP協議

IP提供的是盡最大努力交付的無鏈接服務,所以並不能解決網絡層中的數據報丟失、重複、延遲或亂序等問題,爲了提升IP數據報成功交付的機會, 在網絡層使用ICMP(Internet Control Message Protocol：Internet控制報文協議)協議來容許主機或者路由器報告差錯和異常狀況.

3.4.1 ICMP特徵

a. ICMP就像一個更高層的協議那樣使用IP協議(ICMP消息被封裝在IP數據報中);然而,ICMP是IP的一個組成部分,而且全部IP模塊都必須實現它。
b. ICMP用來報告錯誤,是一個差錯報告機制。它爲遇到差錯的路由器提供了向最初源站報告差錯的辦法,源站必須把差錯交給一個應用程序或採起其它措施來糾正問題。
c. ICMP報文的種類有兩種: ICMP差錯報告報文和ICMP詢問報文;

3.4.2 Ping實現原理

Ping(Packet Internet Groper)分組網間探測是ICMP的一個重要應用,用來測試兩個主機之間的連通性。Ping使用了ICMP回送請求與回答報文。Ping是應用層直接使用網絡層ICMP的一個例子。它沒有經過運輸層的TCP或UDP。
實現原理爲: ping向目的主機發送4個32字節長的ICMP回送請求報文,若目的主機正常工做而且響應了該ICMP回送請求報文,就將發回ICMP回送回答報文。最後可得出的統計結果爲目的IP地址,發送的,收到的和丟失的分組數,及往返時間的最小值、最大值和平均值。

3.4.3 TraceRoute原理

Traceroute(Linux)/tracert(Windows)是用來偵測主機到目的主機之間所經路由狀況的重要工具。
它的原理以下：
源主機首先給目的主機發送一個TTL=1的UDP數據包,而通過的第一個路由器收到這個數據包之後,就自動把TTL減1,而TTL變爲0之後,路由器就把這個包給丟棄了,並同時產生」目的主機不可達」的ICMP差錯報告報文給源主機。源主機收到這個數據報之後再發一個TTL=2的UDP數據報給目的主機,而後刺激第二個路由器給源主機發送差錯報文。如此往復直到到達目的主機。這樣,traceroute就拿到了全部的路由器IP。

4. 傳輸層

傳輸層的主要功能：

傳輸層爲應用進程之間提供端到端的邏輯通訊(網絡層是爲主機到主機提供邏輯通訊)。
複用和分用: 複用是指發送方不一樣的應用進程均可以使用同一個傳輸層協議傳送數據; 分用是指接收方的傳輸層在剝去報文的首部以後可以把這些數據正確交付到目的應用進程.
傳輸層還會對收到的報文進行差錯檢測(首部和數據部分), 而網絡層只檢查IP數據報的首部, 不檢驗數據部分是否出錯。
傳輸層須要有兩種不一樣的運輸協議:面向鏈接的傳輸控制協議 TCP (Transmission Control Protocol)和無鏈接的用戶數據報協議 UDP (User Datagram Protocol);

流量控制與擁塞控制的區別：
流量控制每每是指在發送端和接收端之間的點對點通訊量的控制. 流量控制所要作的是抑制發送端發送數據的速率, 以便使接收端來得及接收;
擁塞控制必須確保通訊子網可以傳送待傳送的數據, 是一個全局性的問題, 涉及網絡中全部的主機、路由器以及致使網絡傳輸能力降低的全部因素.
端口：
端口就是傳輸層的服務訪問點, 用一個16位的數字進行標標記。
端口號只具備本地意義,即端口號只是爲了標誌本計算機應用層中的各進程。在因特網中不一樣計算機的相同端口號是沒有聯繫的。端口的做用是讓應用層的各類應用進程都能將其數據經過端口向下交付給傳輸層,以及讓傳輸層知道應當將其報文段中的數據向上經過端口交付給應用層的哪一個進程。
從這個意義上講,端口是用來標誌應用層的進程;

4.1 TCP三次握手

第一次握手:客戶機的TCP首先向服務器的TCP發送一個鏈接請求報文段。這個特殊的報文段中不含應用層數據,其首部中的SYN標誌位被置爲1。另外,客戶機會隨機選擇一個起始序號seq=x(鏈接請求報文不攜帶數據,但要消耗掉一個序號)。
第二次握手:服務器的TCP收到鏈接請求報文段後,如贊成創建鏈接,就向客戶機發回確認,並在OS內核中爲該TCP鏈接分配TCP緩存和變量。在確認報文段中,SYN和ACK位都被置爲1,確認號字段的值爲x+1(表示但願收到的下一個字節的序號爲x+1),而且服務器隨機產生起始序號seq=y(確認報文不攜帶數據,但也要消耗掉一個序號)。
第三次握手:當客戶機收到確認報文段後,還要向服務器給出確認,而且也要在client端的OS內核中給該鏈接分配緩存和變量。這個報文段的ACK標誌位被置1,序號字段爲x+1,確認號字段爲y+1。

須要注意的是:服務器端的資源是在完成第二次握手時分配的,而客戶端的資源是在完成第三次握手時分配的。這就使得服務器易於受到SYN洪泛攻擊。
爲何須要採用三次握手?
主要是爲了防止兩次握手狀況下已失效的鏈接請求報文段忽然又傳送到服務端,而產生的錯誤。
舉例以下:
客戶A向服務器B發出TCP鏈接請求,第一個鏈接請求報文在網絡的某個節點長時間滯留,A超時後認爲報文丟失,因而再重傳一次鏈接請求,B收到後創建鏈接。數據傳輸完畢後雙方斷開鏈接。而此時,前一個滯留在網絡中的鏈接請求到達了服務端B,而B認爲A又發來鏈接請求,若採用的是「兩次握手」,則這種狀況下B認爲傳輸鏈接已經創建,並一直等待A傳輸數據,而A此時並沒有鏈接請求,所以不予理睬,這樣就形成了B的資源白白浪費了;但此時如果使用「三次握手」,則B向A返回確認報文段,因爲是一個失效的請求,所以A不予理睬,創建鏈接失敗。第三次握手的做用:防止已失效的鏈接請求報文段忽然又傳送到了服務器。

4.2 TCP四次揮手

第一次斷開:客戶機打算關閉鏈接,就向其TCP發送一個鏈接釋放報文段,並中止發送數據,主動關閉TCP鏈接,該報文段的FIN標誌位被置1,seq=u,它等於前面已傳送過的數據的最後一個字節的序號加1(FIN報文段即便不攜帶數據,也要消耗掉一個序號)。
第二次斷開:服務器收到鏈接釋放報文段後即發出確認,確認號是ack=u+1,而這個報文段本身的序號是v,等於它前面已傳送過的數據的最後一個字節的序號加1。此時,從客戶機到服務器這個方向的鏈接就釋放了,TCP鏈接處於半關閉狀態。但服務器若發送數據,客戶機仍要接收,即從服務器到客戶機這個方向的鏈接並未關閉。
第三次斷開:若服務器已經沒有要向客戶機發送的數據,就通知TCP釋放鏈接,此時其發出FIN=1的鏈接釋放報文段,序號爲w(注意: 此時確認號字段值仍爲u+1, 由於這段時間裏, 客戶端並未發送任何數據到服務器)。
第四次斷開:客戶機收到鏈接釋放報文段後,必須發出確認。在確認報文段中,ACK字段被置爲1,確認號ack=w+1,序號seq=u+1。此時TCP鏈接尚未釋放掉,必須通過時間等待計時器設置的時間2MSL後,A才進入到鏈接關閉狀態。

TIME_WAIT狀態：

爲了保證客戶端發送的最後一個ACK報文段可以達到服務器。這個ACK報文段可能丟失,於是使處在LAST_ACK狀態的服務器收不到確認。這樣的話, 服務器會超時重傳FIN+ACK報文段,客戶端就能在2MSL時間內收到這個重傳的FIN+ACK報文段,接着客戶端重傳一次確認,重啓計時器。最後,客戶端和服務器都正常進入到CLOSED狀態。

若是客戶端在TIME_WAIT狀態不等待一段時間,而是在發送完ACK報文後當即釋放鏈接,那麼就沒法收到服務器重傳的FIN+ACK報文段,於是也不會再發送一次確認報文。這樣,服務器就沒法按照正常步驟進入CLOSED狀態。

防止已失效的鏈接請求報文段出如今本鏈接中。客戶端在發送完最後一個ACK確認報文段後,再通過時間2MSL,就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣就可使下一個新的鏈接中不會出現這種舊的鏈接請求報文段。(IP數據報在因特網中的最大生存時間爲MSL)

注意:服務器結束TCP鏈接的時間要比客戶端早一些,由於客戶機(最早提出close請求的一端)最後要等待2MSL後才能夠進入CLOSED狀態。

4.3 TCP vs UDP

TCP：

TCP是一種面向鏈接的(一對一),提供可靠交付的和全雙工通訊的,基於字節流的端到端傳輸層通訊協議。
面向鏈接: TCP在傳輸數據以前必須先創建鏈接,數據傳輸結束後要釋放鏈接。
一對一: 每一條TCP鏈接只能有2個端點,故TCP不提供廣播或多播服務。
可靠交付: TCP提供可靠交付,經過TCP鏈接傳輸的數據,無差錯、不丟失、不重複、而且按序到達。
基於字節流: TCP是面向字節流的。雖然應用進程和TCP的交互是一次一個數據塊(大小不等),但TCP把應用程序交下來的數據僅僅當作是一連串的無結構的字節流, 而並不知道所傳輸的字節流的含義。

UDP：

UDP是一種無鏈接的,盡最大努力交付的和全雙工通訊的,基於報文段的端到端傳輸層通訊協議。
無鏈接: UDP在發送數據以前不須要創建鏈接
盡最大努力交付: UDP不保證可靠交付,主機不須要維持複雜的鏈接狀態
面向報文: UDP是面向報文的。UDP對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的的邊界,即應用層交給UDP多長的報文,UDP就照樣發送,即一次發送一個報文。在接收端,UDP一次交付一個完整的報文, 所以應用程序須要選擇合適的報文大小。
其餘:

UDP沒有擁塞控制,網絡出現的擁塞不會使源主機的發送速率下降。
UDP支持一對1、一對多、多對一和多對多的交互通訊。
UDP的首部開銷小,只有8個字節,比TCP的20個字節的首部要短。

2、HTTP協議

HTTP 協議是無狀態的(stateless),即不須要記憶交互的當前狀態,由於過程簡單。
HTTP 1.0協議是非持續鏈接。創建TCP鏈接後,一個HTTP請求過去,一個HTTP響應過來,而後就斷開TCP鏈接。不一樣於HTTP/1.0,HTTP/1.1 協議使用持續鏈接。
HTTP 使用了面向鏈接的 TCP 向上提供的服務。

1. 報文格式

1.1 請求行

請求行由請求方法字段、URL字段和HTTP協議版本字段3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。
根據HTTP標準，HTTP請求可使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

1.2 請求頭部

請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號「:」分隔。請求頭部通知服務器有關於客戶端請求的信息，典型的請求頭有：
User-Agent：產生請求的瀏覽器類型。
Accept：客戶端可識別的內容類型列表。
Host：請求的主機名，容許多個域名同處一個IP地址，即虛擬主機。

1.3 空行

最後一個請求頭以後是一個空行，發送回車符和換行符，通知服務器如下再也不有請求頭。

1.4 請求數據

請求數據不在GET方法中使用，而是在POST方法中使用。POST方法適用於須要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭是Content-Type和Content-Length。

1.5 GET vs POST

請求數據方式不一樣 GET提交：例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。若是數據是英文字母/數字，原樣發送，若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII。POST提交：把提交的數據放置在是HTTP包的包體＜request-body＞中。所以，GET提交的數據會在地址欄中顯示出來，而POST提交，地址欄不會改變
GET後退按鈕/刷新無害，POST數據會被從新提交（瀏覽器應該告知用戶數據會被從新提交）。
GET書籤可收藏，POST爲書籤不可收藏。
GET能被緩存，POST不能緩存。
GET編碼類型application/x-www-form-url，POST編碼類型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。爲二進制數據使用多重編碼。
GET歷史參數保留在瀏覽器歷史中。POST參數不會保存在瀏覽器歷史中。
GET對數據長度有限制，當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。POST無限制。
GET只容許 ASCII 字符。POST沒有限制。也容許二進制數據。
與 POST 相比，GET 的安全性較差，由於所發送的數據是 URL 的一部分。在發送密碼或其餘敏感信息時毫不要使用 GET ！POST 比 GET 更安全，由於參數不會被保存在瀏覽器歷史或 web 服務器日誌中。
GET的數據在 URL 中對全部人都是可見的。POST的數據不會顯示在 URL 中。

2. HTTP狀態碼

狀態碼	英文名稱	中文描述
100	Continue	繼續。客戶端應繼續其請求
101	Switching Protocols	切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200	OK	請求成功。通常用於GET與POST請求
204	No Content	無內容。服務器成功處理，但未返回內容。在未更新網頁的狀況下，可確保瀏覽器繼續顯示當前文檔
206	Partial Content	部份內容。服務器成功處理了部分GET請求
301	Moved Permanently	永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替
302	Found	臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI
304	Not Modified	未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端一般會緩存訪問過的資源，經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源
400	Bad Request	客戶端請求的語法錯誤，服務器沒法理解
401	Unauthorized	請求要求用戶的身份認證
403	Forbidden	服務器理解請求客戶端的請求，可是拒絕執行此請求
404	Not Found	服務器沒法根據客戶端的請求找到資源（網頁）。經過此代碼，網站設計人員可設置"您所請求的資源沒法找到"的個性頁面
500	Internal Server Error	服務器內部錯誤，沒法完成請求
502	Bad Gateway	充當網關或代理的服務器，從遠端服務器接收到了一個無效的請求
503	Service Unavailable	因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504	Gateway Time-out	充當網關或代理的服務器，未及時從遠端服務器獲取請求
505	HTTP Version not supported	服務器不支持請求的HTTP協議的版本，沒法完成處理

3. 常見請求字段

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	逐跳首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Transfer-Encoding	指定報文主體的傳輸編碼方式
Accept	表明發送端（客戶端）但願接受的數據類型,如application/json、text/plain、text/html、image/jpeg、application/msword、image/png、application/pdf
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言
Host	指定資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與If-Match相反）
Referer	對請求中URI的原始獲取方
User-Agent	Http客戶端程序的信息
Accept-Range	是否接受字節範圍請求
ETag	資源的匹配信息
Location	另客戶端重定向至指定URI
Server	Http服務器的安裝信息
Vary	代理服務器緩存的管理信息

4. HTTP長鏈接和短鏈接

在HTTP/1.0中，默認使用的是短鏈接。
從 HTTP/1.1起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的HTTP協議，會在響應頭有加入這行代碼：Connection:keep-alive在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如Apache）中設定這個時間。實現長鏈接要客戶端和服務端都支持長鏈接。

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

短鏈接的操做步驟是：
創建鏈接——數據傳輸——關閉鏈接…創建鏈接——數據傳輸——關閉鏈接
長鏈接的操做步驟是：
創建鏈接——數據傳輸…（保持鏈接）…數據傳輸——關閉鏈接

5. HTTP2.0的優勢

採用二進制格式傳輸數據也能夠理解爲流式傳輸，非HTTP1.1的默認文本格式，並對消息頭進行HPACK壓縮
TCP多路複用,多個請求併發完成,與HTTP1.1的長鏈接的串行傳輸效率更高
支持傳輸流的優先級控制
支持服務端推送
參考文章： HTTP/2 頭部壓縮技術介紹

6. HTTPS協議

目前經常使用的加密算法主要分紅對稱加密算法與非對稱加密算法
對稱加密算法
發送方和接收方須要持有同一把密鑰，發送消息和接收消息均使用該密鑰。
相對於非對稱加密，對稱加密具備更高的加解密速度，但雙方都須要事先知道密鑰，密鑰在傳輸過程當中可能會被竊取，所以安全性沒有非對稱加密高。
非對稱加密算法
接收方在發送消息前須要事先生成公鑰和私鑰，而後將公鑰發送給發送方。發送放收到公鑰後，將待發送數據用公鑰加密，發送給接收方。接收到收到數據後，用私鑰解密。在這個過程當中，公鑰負責加密，私鑰負責解密，數據在傳輸過程當中即便被截獲，攻擊者因爲沒有私鑰，所以也沒法破解。非對稱加密算法的加解密速度低於對稱加密算法，可是安全性更高。

參考文章：