網絡知識 - 網絡傳輸協議
網絡傳輸協議（Network Transfer Protocol）
在計算機網絡通信的世界裏，協議是指兩臺計算機之間為了實現相互通信由萬維網所發布的一個雙方認同並約定的規範，
兩種網絡地址
mac地址
計算機硬件廠商在出廠網卡時為網卡設計的具有能標識這塊網卡的唯一性的地址，具有唯一性。當N臺計算機在局域網中進行通信時，它們需要遵守鏈路層協議，這個協議規定計算機發送數據給另一臺計算機時需要提供自己的地址，這個地址就是mac地址，用來表示計算機自身。
IP地址
互聯網絡是高於局域網絡的更高級別的抽象，它統領處於不同鏈路層協議的各個局域網。為此，就需要為每一個能連接到互聯網的計算機設計一個具有能標識這臺計算機的唯一性的地址，這個地址就是IP地址，用來表示計算機自身。
mac與IP的異同
都能用來表示網絡地址，但一個是屬於局域網的，另一個屬於互聯網。可以稱mac是物理地址，IP是虛擬地址，但它們都具備唯一性。在命令行輸入ipconfig/all可以查看本機的mac地址和網絡IP地址，如果是wifi連接，還可以看到路由器的mac地址和網絡IP地址。
三種網絡
局域網
一根網線，點對點就能搭建一個局域網，通常使用交換機搭建局域網，A將封裝了B的mac地址的數據傳輸至交換機，由交換機取出封裝在數據中的接收方的mac地址，然後從註冊在mac表中的地址列表中找出匹配的目標地址，如果匹配成功則轉發數據。
廣域網
比局域網更大的由多個局域網組成的網絡。A傳輸數據到交換機x，由交換機x傳輸至另一個局域網中的交換機y，由y將數據轉發至處於y網下的接收方B。
互聯網
將所有局域網、廣域網連接成一個整體。
網絡分層協議（實現網絡、實現互通的技術規範）
可以把每臺獨立的計算機想象成兩個來自不同國家的人（A和B），他們因地域文化語言的障礙而無法暢快的溝通，所以計算機之間要相互通信是一個復雜的技術問題，為了能使他們進行有效的溝通交流，就出現了協議。計算機之間的通信是基於約定，也即，當A和B約定了SOS==求救，那麽在這個約定之下，當A發出SOS的數據到B處時，B就知道這是一個求救的請求。如果沒有這個約定，那麽A發出SOS信號到B處，B就不知道如何做出處理。所以，簡言之，協議就是雙方約定的規範，目的是能理解對方的意圖並因此做出回應。在計算機網絡通信中，協議被分為5個層，A、B雙方都必須遵守每個層的協議才能實現通信。比如發起一個http請求就是發起一個基於http協議規範的請求。而這些協議說穿了就是技術守則、技術手段，雙方只要利用這些約定的技術標準、技術規格就可以搭建起一個網絡，就能夠使計算機之間的相互通信成為可能。這些協議層包括了實現通信的物理技術規範、處理數據的格式規範等等。網絡協議保證了可讀數據在整個轉換和傳輸過程中的完整性。
物理層（physical layer)
處於物理層的對象：光纖、電纜、電磁波
物理層包含的技術規範：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45
物理層協議：規範承載數據的載體。計算機中的數據都是0和1的數字序列，而0和1的序列總是需要利用某種現實世界的物質作為載體，需要某種媒介予以表示。規範這一實現的就是物理層協議。載體就是光纖、電纜，媒介是光電（ 高電平（1）和低電平（0））。
當一臺計算機使用了光纖作為傳輸媒介，它就具備了與另一臺計算機進行通信的基礎。
鏈路層(link layer)
處於鏈路層的對象：統管基於相同鏈路層協議的計算機的網絡，我們熟知的以太網技術和Wifi技術就是不同的鏈路層協議。如：有線局域網絡（以太網）、無線局域網絡（Wifi）
鏈路層包含的協議：[廣域網：HDLC、PPP、SLIP]、[局域網：MAC子層協議 | LLC子層協議]
鏈路層協議：規範雙方傳輸數據的格式，A、B雙方按照鏈路層的協議將發送的數據封裝為數據幀（Frame），幀必須含有以下三種格式的數據：
1.發送方的mac地址（Source）
2.接收方的mac地址（Destination）
3.數據（Payload）
3.測試數據錯誤的校驗序列（Check）
當N臺計算機都遵守了物理層和鏈路層的協議後，它們就可以搭建起一個局域網絡，實現互通。
網絡層（network layer）
處於網絡層的對象：統管基於不同鏈路層協議的計算機的中間人，如：路由器
網絡層包含的協議：IP協議、ICMP協議、RAP協議、RARP協議
網絡層協議：規範基於不同的鏈路層協議的N臺計算機進行通信的傳輸數據的格式，因為基於不同的鏈路層協議的兩臺計算機不能進行有效的通信，無法溝通，A無法適應B，因為他們的鏈路層的規範不一樣，而網絡層協議則充當了翻譯的角色，網絡層對象必須具備以下能力：
1.能接收和發送來自基於不同鏈路層協議的計算機的數據
2.能有效識別A發給B的數據，並把幀封裝的數據取出來重新封裝為包（Packet），再轉發給B。既然如此，那麽網絡層對象就可能需要遵守多個鏈路層協議規範才能充當統管和翻譯的角色。包必須含有以下幾種格式的數據：
1.發送方的IP地址（Source）
2.網絡層對象的IP地址（Destination）
3.接收方的IP地址（Destination）
4.數據（Payload）
5.測試數據錯誤的校驗序列（Check）
當N臺計算機都遵守了物理層、鏈路層和網絡層的協議後，它們就可以搭建起一個互聯網絡，由網絡層對象負責分發IP給它們，實現互通。
傳輸層(transport layer)
傳輸層包含的協議：TCP協議 | UDP協議 | TLS協議 | SSL協議
傳輸層協議：規範本地計算機的各個需要網絡通信的應用程序進程的端口號，當A計算機的某個進程把數據發送至B計算機，只有B計算機可以接收到數據，但是A的某個進程實際上是需要將數據發送給B計算機的某個進程，這是一個需要解決的問題，針對這個問題，傳輸層規範了本地端口號，如果A計算機的x進程想要將數據發送至B計算機的y進程，那麽x進程除了需要提供B計算機的mac地址或IP地址外，它還需要提供y進程的端口號才可以。數據送達B計算機後，由B的某個操作系統進程根據端口號將數據轉發給y進程。處於此層的數據稱為段（Segment）。
當N臺計算機都遵守了物理層、鏈路層、網絡層、傳輸層的協議後，它們各自的進程之間就能實現傳輸數據。
應用層(application layer)
處於應用層的對象：應用程序
應用層包含的協議：HTTP協議 | FTP協議 | IMAP協議 | DNS協議 | NNTP協議
應用層協議：規範處於任何網絡中的計算機的各個需要網絡通信的應用程序進程的專用數據規範，比如Ftp（文件傳輸協議）、Http（超文本傳輸協議）、Imap（電郵協議）、Dns協議（域名系統服務協議）、Nntp（新聞傳輸協議）。
數據傳輸時的封裝過程
發送方發送的數據都是以應用層為起點，一步一步經過每一個層對數據進行封裝處理後發送到接收方，接收方接收到數據後，需要一步一步進行拆封，直到露出最基本的原始數據為止。發送數據時，是從應用層開始向物理層傳遞數據，每一層都會對數據附加一個頭部信息（報文頭部），對數據加以封裝，頭部信息包含了發送方和接收方的地址和一些控制傳輸行為的指示性數據，封裝完成後會繼續往下一層發送。見下圖，其中的表示層和會話層沒有協議。
1.應用層針對具體的應用層協議對數據進行格式化處理，比如http協議會將數據格式化為帶有請求行、消息報頭、請求正文的規範數據體。
2.傳輸層為數據附加頭部信息，這包括雙方進程端口號
3.網絡層為數據附加頭部信息，這包括雙方ip地址
4.鏈路層為數據附加頭部信息，這包括雙方mac地址
5.物理層以二進制格式傳輸數據
ARP協議獲取接收方的mac地址
ARP協議處於網絡層，它的作用是將接收方的IP地址轉化成物理地址，從上圖中可以看到，發送方將數據層層封裝後根據IP地址發往接收方，數據到了接收方後會首先進入鏈路層，鏈路層將數據拆包後發現發送方沒有填寫目標mac地址，因為發送方只知道目標（接收方）的網絡IP，所以mac被看成是null，這與接收方的mac地址不匹配，這樣，數據包會被丟掉。ARP協議則規範了發送方發起傳輸請求的時候得實現ARP規範，這樣，請求發起時會預先向網絡發起廣播咨詢，咨詢會詢問處於同一個網絡中的所有主機：我要發送數據的接收方的IP所對應的mac地址是什麽，所有主機都會偵聽到這個請求，而具有與IP對應的mac地址的主機則會做出應答，它會將自身的mac地址發送給對方。這樣，當原來作為發送方的對象得到目標mac地址後就會再發起一個請求，將目標mac地址封裝在請求中。這樣，目標方就能夠匹配這個物理地址從而接收數據包。每一個支持ARP協議的計算機都會創建一個ARP緩存表，用以存儲已經詢問過的IP所對應的mac地址，當下一次再對一個之前已經詢問過的IP發起傳輸請求時，系統會可以自動從緩存表中找到IP所對應的mac地址了。在一段時間內如果表中的某一行沒有使用，就會被刪除，這樣可以大大減少ARP緩存表的長度，加快查詢速度。通過持續不斷的偽造ARP應答可以使網絡堵塞，因為A廣播請求詢問某個目標IP的mac地址，能匹配這個mac地址的主機就會進行回應，但黑客會主動應答詢問者，將偽造的mac地址發送給詢問者。這樣，系統將錯誤的mac地址更新到緩存表，如果黑客大量的偽造ARP應答就會使大量計算機發起的請求得不到回應從而產生大量的網路阻塞，而且黑客如果將自己主機的mac地址響應給詢問者，那麽詢問者就會再毫不知情的情況下向黑客傳輸私密數據，成為安全隱患。
TCP協議的三次握手和四次分手
三次握手
TCP連接處於傳輸層，當需要傳輸數據到目標地址端口號時，會預先發送一個主動要求建立關系的SYN數據包，SYN表示要求與接收方同步建立連接，接著接收方會發送一個SYN+ASK數據包做為對請求的應答，再接下來源發送方會發送一個ASK數據包作為應答，這樣經過三次的握手，關系正式建立，可以傳輸數據了。
為什麽需要三次確認？似乎，當我發給你數據後，只要你能回復我，我能接到你的回復，則已經證明信道是通暢的，為什麽還要再握手一次才能正式傳輸數據？這是因為我能接收到你的數據（第二次握手），你也能接收到我的數據（第一次握手），這都是站在我這方（單方面）來考慮信道是否通暢，因為我只能確認你能成功發送數據給我（第二次握手）同時我也能發送數據給你（第一次握手），but，你並不能確定你發送的數據成功到了我這裏，so，兩次握手只能讓我確認我們可以正確傳輸數據，而你最多只能確認我可以發數據給你，但不能確認你的數據能不能成功發送到我這裏。
四次分手
為什麽需要四次才能徹底分手？因為一次只能應答一個問題，所以（第1次）當A方發送數據包通知B方，我已經沒有數據向你發送了，（第二次）B方只能發起一個應答數據包表示Ok，我已經知道了，（第3次）然後B再次發起一個數據包表示我也沒有數據向你發送了，（第4次）A回應B，Ok，我們結束通信。
TCP協議的報頭
TCP協議的報頭數據是為了描述建立的TCP連接的狀態。TCP封裝數據後的報文頭如圖所示：
下面對上圖中比較重要的兩個項做出解釋：
1.序列號（Seq）
發送方發送的數據包的序號，比如向接收方發出數據包時，數據包中的頭部總是含有Seq的值，這個值表示目前向接收方發出的數據包的個數，幾乎都是從x開始，這個起始值可能是隨機變量值，通常從0開始，但下一次發起則會++，也即第一次發起數據包Seq=0，第二次發起數據包則Seq=1，以此類推。為了方便記憶，可以這樣描述：這是我要向你發送的第x個包，下一次再發送則x++。
2.確認號（Ack）
可以這樣描述：我要求你發送給我第x++個包。
2.控制位（ControBits Flag）
ControBits Flag是位標誌枚舉，用來表示發出的數據包的類型，可能的值如下：
URG：URG數據包，保證TCP連接不被中斷，並且督促中間層設備要盡快處理這些數據，當應用了此項時，緊急指針才有效。PSH：PSH數據包，表示數據包到達接收端以後，應立即傳送給應用程序，而不要進入緩沖區隊列。
RST：RST數據包，表示重置連接，應對產生錯誤的、非法的數據連接。
FIN：FIN數據包，表示數據流已達到末尾，傳輸完成，連接將被斷開。
ACK：ACK數據包，表示應答信號。註意這個ACK和確認號的Ack不是一個概念，只是名稱相同。
SYN：SYN數據包，表示要求建立連接的信號。
Http協議
Http協議是處於應用層面的、規範數據傳輸格式的協議。由萬維網協會（World Wide Web Consortium [ www ] ）和 Internet 工作小組（ Internet Engineering Task Force [IETF] ）聯合發布。
協議規範
1.http協議的默認端口：80、https協議的默認端口：4432.客戶端發起請求，請求中包含自身的網絡IP和進程的端口號，服務端響應請求
3.每個請求會先進入隊列，服務端一次處理一個請求，處理完畢就會釋放建立的連接（客戶端IP和端口與服務端IP保持通信），清空服務端資源
4.無狀態，所謂無狀態，是指基於Http協議的數據傳輸是一次性的，在客戶端發起請求到服務端接收到請求的這個期間的一切數據僅在此時此刻有效，
離開這個期間，一切回歸平靜，不起一絲波瀾。在這個期間，客戶端和服務端是朋友關系，建立起一個連接。
服務端處理完請求後，有關這個請求的Http數據就會消失，也即，服務端是從基於Http協議傳輸的數據來和你建立關系，
數據傳輸過來，服務端做出處理，然後你的數據會被忘掉。當你下一次再和服務端建立連接時，即使你帶著自身的網絡ip和端口號，
他也會以為你是一個全新的朋友。http的設計之初就是為了使其健忘，減少服務端的內存占用，免得服務端不堪重負，存儲一大堆舊數據。
http協議的健忘癥屬於先天缺陷，他只保持一次性的傳輸，之後什麽都不記得，傳輸完成，馬上被清除掉，服務端繼續接待下一個客戶端的請求。
別跟服務端提因為以前你們認識所以這次請求可以省略一些必要的Http數據，這是行不通的，別跟服務端說我之前給過門票（請求），
我不過是出去上個廁所你TM的就不認識我了。再打個比方，一個登陸頁面提供了用戶名和密碼，你填寫完後提交到服務端，
這些http數據到達服務端被處理之後就會被丟掉，當你下一次繼續請求某個需要權限（已登錄用戶）的資源但你又沒有繼續提供前一次提供的用戶名和密碼時，
服務端就會給阻止你，也即你必須提供之前那個請求所提供的完全相同的登錄數據才可以。為了解決http的無狀態性，
瀏覽器都支持cookie，cookie可以存儲已登錄用戶的信息，所以下一次當你再發起請求時卻並不提供你的登錄名和密碼，
服務端也不會因為不知道你是誰從而阻止你對某個需要權限的資源的請求，因為服務端由開發人員編寫的程序會從cookie中讀取你的身份信息，
這樣，http看起來似乎就不再那麽健忘了，實際上它還是健忘的，總之，它的有效性只在從客戶端傳輸到服務端為止，記住這一點即可！
5.保持連接，Http1.0版本中會針對每一個請求建立一個TCP連接。也即，一個網頁的http請求如果包含其它http請求，
那麽一次只處理一個，比如網頁可能包含了對css，js等的請求，這些請求只能等待第一個請求被處理完成，
連接已經釋放後，才會被發送到服務端，這樣會再次建立新的tcp連接。在http.1版本的協議中，
針對來自同一ip的多個http請求只會建立一個連接，也即客戶端可以連續發送多個http請求到服務端進入隊列，
服務端依次處理完之後，釋放連接。好處在於節省了創建連接的時間。從HTTP/1.1起默認都開啟了Keep-Alive（ 保持連接 ），
但即使一直保持著雙方的通信連接也並不改變http的無狀態。連接的保持只是為了節省建立連接的時間而已，
免得下次請求時又要重新創建連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。
6.一個http鏈接就是一個http請求，通常一個網頁程序包含N個http請求，比如頁面中會請求js和css、圖片資源等等。
Http報文
客戶端發起請求的數據或服務端做出回應的數據都是經過http.sys封裝成http報文後向各個OSI層傳遞，層層封裝，最後通過光纖傳輸至目標計算機，目標計算機再層層拆包，最終將數據傳輸至處於目標端口號的應用程序（瀏覽器）之中，所以我們可以在瀏覽器通過開發人員工具看到http報文。
請求報文的格式
響應報文的格式
報頭
報文的首行只是對報文的簡短描述，而報頭是對報文的詳細描述和對請求、回應的控制、報頭的值稱為指令，用於控制服務端和客戶端交互的行為，多個指令可用逗號隔開。除了請求報頭Host是必須的，其它報頭都是可選的。
請求頭
Referer：Referer:http://translate.google.cn通知服務端，我是通過指定的服務端的鏈接向你這個服務端發起請求的。
Connection：keep-alive | close
值1提醒服務端，應建立持久的TCP連接。值2提醒服務端傳輸完成立即釋放TCP連接。
Host：blog.csdn.net
我請求的資源所在的域名和端口號，默認80端口，80不顯示。
Cookie：xxx
存儲的cookie。
Content-Length：80
我發起的請求，其正文的長度。
Authorization：xx
我的授權信息存儲在此處。服務端可以讀取並做出測試。
UA-Pixels：xx
我屏幕的大小。
UA-Color：xx
我屏幕的顏色深度。
UA-OS：xx
我的操作系統。
UA-CPU：xx
我的CPU類型。
Range：ranges-specifier = byte-ranges-specifier
我將請求端點續傳功能，需要服務端確認，可利用端點續傳使用多線程下載軟件對資源進行分塊下載。 當用戶在聽一首歌的時候，如果聽到一半（網絡下載了一半），網絡斷掉了，
用戶需要繼續聽的時候，文件服務器不支持斷點的話，
則用戶需要重新下載這個文件。而Range支持的話，
客戶端應該記錄了之前已經讀取的文件範圍，網絡恢復之後，
則向服務器發送讀取剩余Range的請求，服務端只需要發送客戶端請求的那部分內容，
而不用整個文件發送回客戶端，以此節省網絡帶寬。
如果服務端支持Range，首先要通知客戶端（response.setHeader(‘Accept-Ranges‘, ‘bytes‘)），
之後客戶端才可以發起帶Range的請求。可以請求一個資源多個子範圍。
如：
表示請求服務端發送500個字節給我：bytes=0-499
表示從上次的位置開始再續傳500字節給我：bytes=500-999
表示最後再續傳500個字節給我：bytes=-500
表示續傳從第500字節開始及其以後的字節給我：bytes=500-
第一個和最後一個字節：bytes=0-0,-1 續傳該資源的第306302到604047個字節，該資源共604048個字節：Content-Range: bytes 306302-604047/604048
同時指定幾個範圍：bytes=500-600,601-999
續傳總是以狀態碼206返回，表示ok。
If-Modified-Since:GMT時間
服務端總是返回一個靜態的html資源，
而客戶端首次請求時會將服務端返回的html緩存起來，
並把該資源傳輸到本地時的時間寫入緩存表中，
當下一次發起相同的url請求時，
客戶端會將該url對應的資源在緩存表中的緩存時間發送到服務端，
服務端IIS會自動讀取該資源在服務端中的最後修改時間，
如果這個時間小於客戶端發送的時間，則判定不需要響應這個資源，直接返回http狀態碼304，
客戶端接到這個狀態碼後會從換存中讀取文件。否則判定需要響應更新的資源給客戶端，直接返回http狀態碼200和資源，
客戶端接收到狀態碼後會用新資源替換舊資源，並將新資源傳輸到本地時的時間更新到緩存表。
If-None-Match：33a64df551425fcc55e4d42a148795d9f25f89d4
ETag：33a64df551425fcc55e4d42a148795d9f25f89d4
If-None-Match頭由客戶端發送，ETag頭由服務端發送。每個資源的最後修改時間都交給IIS，
由IIS計算資源的時間戳，當我首次請求某個資源時，
服務端會自動將這個時間戳放在ETag響應頭之中，
當下一次我發起相同的url請求時，會將這個時間戳放在If-None-Match請求頭之中，
如果兩個時間是一樣的，則服務端判定不需要響應這個資源，
直接返回http狀態碼304，我接到這個狀態碼後會從換存中讀取文件。
否則判定需要響應更新的資源給客戶端，直接返回http狀態碼200和資源。
時間戳的算法機制不明，但推薦使用，只需要配置IIS的http響應頭的ETag即可。具體配置如下：
在web.config中配置“ ”
<system.webServer>
<httpProtocol>
<customHeaders>
<add name = "ETag" value="""" />
</customHeaders>
</httpProtocol>
</system.webServer>
或在IIS中配置：
Pragma：no-cache
通知服務端我沒有緩存該資源，請返回請求的資源的最新版。
Cache-Control：no-cache | no-store | max-age | max-stale | min-fresh | only-if-cached
緩存控制策略，這是一種雙方的約定，取值可以對緩存進行控制，通過設置不同的Cache-Control來控制瀏覽器、服務端甚至Web代理對緩存的使用策略。 取值：
no-cache：通知服務端檢測ETag的值，如果ETag的值與我發送的If-None-Match是一樣的，則我會從換存中獲取資源，否則，請服務端返回資源的最新版本。
no-store：我沒有緩存所請求的資源。
響應頭
多個控制指令以逗號隔開。
ETag：33a64df551425fcc55e4d42a148795d9f25f89d4資源的校驗碼，與客戶端使用If-None-Match配合以便驗證資源是否被修改過從而使客戶端采取緩存讀取文件或從我這裏重新返回資源的新版本的策略。
Last-Modified：Tue, 08 Feb 2022 11:35:14 GMT
表明資源的最後修改日期。
Content-Type：application/x-www-form-urlencoded | application/json ……
通知客戶端，我發送的數據的編碼方式，編碼方式由開發人員設置表單的EncType屬性來指定，EncType用於指示在發送到服務器之前應該如何對表單數據進行編碼。默認使用"application/x-www-form-urlencoded"進行編碼，以下是表單的EncType和Content-Type的取值，兩者的取值是完全對應的。
application/x-www-form-urlencoded 默認編碼方式，提交的數據是以鍵值對的形式提交，比如name字段的值是sam，則提交的數據為：name:sam，服務端使用索引或key從數組中提取值
application/json 編碼為JSON格式，提交的數據是以Json對象的形式提交，比如name字段的值是sam，則提交的數據為：{ name : ‘sam‘ }
text/html 編碼為HTML格式
text/plain 編碼為純文本格式編碼
text/xml 編碼為XML格式編碼
image/gif 編碼為gif圖片格式編碼
image/jpeg 編碼為jpg圖片格式編碼
image/png 編碼為png圖片格式編碼
application/xhtml+xml 編碼為XHTML格式編碼
application/xml 編碼為XML數據格式編碼
application/atom+xml 編碼為Atom XML聚合格式編碼
application/pdf 編碼為pdf格式
application/msword 編碼為Word文檔格式
application/octet-stream 編碼為二進制流數據（如常見的文件下載）
encType multipart/form-data 編碼為上傳文件的格式
Content-Range：bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
用於表明整個返回的資源數據中某一段數據的插入位置和整個資源數據的長度。
例如，傳送頭500個字節中的子數據：Content-Range:bytes0-499/1234
Content-Length：19847
表明返回到客戶端的數據的字節大小。
Content-Encoding：gzip | deflate
表明返回給客戶端的數據的壓縮方式
Content-Language：zh-CN | zh | en-US | zh-HK
指定我發送的文件的語言類型，默認任何語言。
Server：Server: Microsoft-IIS/7.5
表明我使用的哪種軟件承載HTTP服務器。
X-AspNet-Version：4.0.30319
表明ASP.NET的版本。
X-Powered-By：ASP.NET
表明網站是用什麽技術開發的。
Connection：keep-alive | close
值1提醒客戶端，應建立持久的TCP連接。值2提醒客戶端傳輸完成立即釋放TCP連接。
Location：http://xxx
此處表明以前的域名不可用，需要重定向到一個新的位置，此響應頭常用在更換域名的時候。
Refresh：http://xxx
表明瀏覽器應在多少秒之後刷新文檔，只刷新一次。
也可以通過編程或html編碼的方式刷新一次文檔。
編程設置自動刷新一次：setHeader("Refresh", "5; URL=http://host/path")
html編碼設置：在head標簽中設置
<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">
連續刷新需要求每次都發送一個Refresh頭，而發送http狀態碼204則可以阻止瀏覽器繼續刷新。
WWW-Authenticate：Basic realm = "Basic Auth Test!"
向客戶端表明它還未授權，需要客戶端發送請求，請求必須包含Authorization報頭，由Authorization報頭提供身份信息。
Allow：get | post | put | delete……
我支持的請求方式
Date： Tue, 08 Feb 2022 11:35:14 GMT
我返回資源的時間
Expires: Tue, 08 Feb 2022 11:35:14 GMT
通知客戶端瀏覽器，當前請求的資源會在指定時間後過期，此時間後應重新從服務器獲取。
P3P：CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR
跨域設置Cookie, 以便解決iframe跨域訪問cookie的問題
Set-Cookie：sc=4c31523a; path=/; domain=.acookie.taobao.com
我向客戶端寫入的cookie數據。
Cache-Control：public | private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage
緩存控制策略，這是一種雙方的約定，取值可以對緩存進行控制，通過設置不同的Cache-Control來控制瀏覽器、服務端甚至Web代理對緩存的使用策略 取值：
Public（ 啟用了任何客戶端或代理端對資源進行緩存的功能 ）
Privat（ 禁用了代理端對資源進行緩存的功能 ）
no-cache（ 我將檢測客戶端發送的 If-None-Match請求頭，如果與ETag一樣則通知客戶端從緩存中取數據，否則我將返回資源的最新版本 ） no-store（ 通知客戶端不要緩存所請求的資源 ） max-age（ 指示客戶端使用緩存讀取資源的最大秒數，超過此秒，則我會返回資源的最新版本 ） min-fresh（ 超過指定秒數，我將不再返回資源給客戶端 ）
max-stale（ 即使超過指定秒數，我也會返回資源給客戶端 ）
保持Http的狀態（session）
使用url查詢字符串保持狀態
將數據附加到url查詢變量中，以此保持狀態。
使用隱藏域保持狀態
將數據存入隱藏域隨表單提交，服務端再把數據發往隱藏域存儲，以此保持狀態。
使用cookie保持狀態
向客戶端寫入加密的cookie，以此保持狀態。
使用Seesion保持狀態
session不屬於http協議，而為了解決http協議的無狀態，比如使用session來保持用戶的登錄狀態，session存儲在服務端內存中，而cookie存儲在客戶端瀏覽器中，但session的key是寫入cookie中的，如果客戶端禁用cookie，還可以通過將sessionID附加url查詢字符串將中。
Http請求
http請求總是以一個Url鏈接的格式發起，每一個鏈接就是一個http請求。一個Url地址描述的是請求的資源在網絡上的位置。
ProtocolName://host[:port]/path/.../[?query-string=value&query-string=value][#anchor]http | https | ftp://域名[:端口號]/資源路徑?查詢字符串=值&查詢字符串=值/#錨鏈接
http代理服務器
http代理服務器處於網絡分層中的會話層，它是客戶端的"服務器"，是目標服務器的"客戶端"。
虛擬主機
提供商把自己的網絡服務器分成N組虛擬空間，這樣的空間稱為虛擬主機，虛擬主機都具有一定的磁盤空間來存儲用戶的web程序、應用組件和資源。
參考資料
微醺歲月：TCP協議的三次握手和四次分手
深海的小魚兒：ARP 數據包格式分析
Du YueHan：TCP的握手分手八卦細節
中國科學技術協會：面向連接的網絡層協議
維基百科：資料鏈結層（Data Link Layer）
維基百科：ARP欺騙
法本如是：HTTP之Range理解
WebWalker：如何統一負載均衡環境中IIS的Etag值以提高訪問速度
唐無敵：http 401Basic驗證和WWW-Authenticate、Authorization
zzfx：怎樣決定一個資源的Cache-Control策略
站長之家：ETag使用效果對比及經驗分享
網絡知識 - 網絡傳輸協議