計算機網路體系結構

隨著互聯網的發展，某些應用程式可以直接使用IP層，甚至直接使用最下面的網路介面層，（例如：分組網間探測PING，用來測驗兩臺主機之間的連通性，PING使用了ICMP回送請求與回送回答報文，）

各層簡介：

應用層：
應用層的任務是通過應用行程間的互動來完成特定網路應用，
應用層協議定義的是應用行程間通信和互動的規則，（DNS,HTTP,SMTP等）

運輸層：
運輸層的任務就是負責向兩臺主機中行程之間的通信提供通用的資料傳輸服務，
主要使用以下兩種協議
(傳輸控制協議TCP、用戶資料報協議UDP)

網路層：
網路層負責為分組交換網上的不同主機提供通信服務（IP協議）

資料鏈路層：
負責互聯設備之間傳送和識別資料幀（資料幀與位元流之間的轉換）

物理層：
負責位元流與電子信號之間的轉換

網路介面層

物理層

物理層考慮的是怎樣才能在連接各種計算機的傳輸媒體上傳輸資料位元流，而不是指具體的傳輸媒體，

物理層主要任務可以認為是確定與傳輸媒體的介面有關的一些特性：介面電壓、形狀尺寸、引腳數目等等，

物理層將網路互相連接起來使用的中間設備是轉發器

資料鏈路層

計算機與外界局域網的通信要通過網路配接器，他又稱網路介面卡或網卡，計算機的硬體地址就在配接器的ROM中，以太網的硬體地址，即MAC地址實際上就是配接器地址，與主機所在的地點無關，源地址和目標地址都是48位長，

發送資料時：
資料鏈路將網路層交下來的IP資料報組裝成幀， 每一幀包括資料和必要的控制資訊（同步資訊、地址資訊：發送端MAC地址、差錯控制等）

接收資料時：
接收端可以根據控制資訊知道一個幀從哪個位元開始和到哪個位元結束，這樣，資料鏈路層在收到一個幀后，就可以從中提取出資料部分，上交給網路層，
根據包的結構圖可以看出，在資料鏈路層是通過包頭中接收端的MAC地址來判斷是否是發送給自己的資料包，進而判斷是否接受，

而且控制資訊還使接收端能夠檢測到所收到的幀中有無差錯，
現實的通信鏈路不理想，也就說，位元在傳輸程序中可能會產生位元差錯（1可變成0，0可變成1），如有差錯，將簡單的丟棄這個差錯幀，以免繼續在網路中傳送下去白白浪費網路資源，
采用CRC回圈冗余檢驗技術可以做到對幀的無差錯接受， 而幀檢驗序列FCS就是添加在資料包后面的冗余碼，

注意：只能保證收到的幀是位元沒有出現差錯的，但無法確定收到的幀是否重復了、缺失了、或是失序了，（提供的是不可靠的傳輸）

資料鏈路層將網路互相連接起來的中間設備叫做網橋或橋接器

網路層（IP協議）

互聯網采用的設計思路：網路層向上只提供簡單靈活的、無連接的、盡最大努力交付的資料報服務（IP資料報）.
網路在發送分組時不需要先建立連接，每一個分組獨立發送，也不進行編號，網路層不提供服務質量的承諾，也就是說，所傳送的分組可能出錯、丟失、失序，當然也不保證分組交付的時限，這種不可靠傳輸服務，就使得網路中的路由去比較簡單，且價格低廉，

網際協議IP

IPv4

長度為四個位元組，32位，

IP分類：


網路號為127保留作為本地軟體測驗環回地址，若主機發送一個目的地址為環回地址的IP資料報，則本機中的協議軟體就處理資料報中的資料，而不會把資料報發送到任何網路，目的地址為環回地址的IP資料報永遠不會出現在任何網路上，因為網路號127的地址根本不是一個網路地址，


作業流程：通過路由器的路由轉發表一級一級不斷改寫為下一跳IP和MAC地址，最終的找到目標IP和目標MAC地址，

IPv6

IPv4的地址耗盡，ISP已經不能再申請新的IP地址塊了，所以采用具有更大地址空間的新版本IP，即IPv6,，

IPv6把地址從32位擴大到128位，

地址決議協議ARP

ARP協議的用途是為了從網路層使用的IP地址，決議出在資料鏈路層使用的硬體地址，

網路層使用的是IP地址，但在實際的網路的鏈路上傳送資料幀時，最侄訓是必須使用該網路的硬體地址，

作業原理：
每一臺主機都設有一個ARP高速快取，里面有本局域網上的各主機和路由器的IP地址到硬體地址的映射表，并且這個表還經常動態更新，

當主機A要向本局域網上的某臺主機B發送IP資料報
1、先在其ARP高速快取中查看有無主機B的IP地址，如有，就在表中查出對應硬體地址然后寫入MAC幀，最后通過局域網把該MAC幀發往此硬體地址，

2、如果查不到主機B的IP地址項，可能是主機B剛入網，也可能主機A剛加電，高速快取還是空的，這種情況下，主機A自動運行ARP廣播，然后B單播回應A. 最后A獲得了B的MAC地址，

網際控制報文協議ICMP

為了更有效地轉發IP資料報和提高交付成功的機會，在網際層使用了ICMP協議，ICMP協議允許主機或路由器報告差錯情況和提供有關例外情況的報告，ICMP協議是IP層協議，不是高層協議，因為ICMP是作為資料部分裝在IP資料報中的，

ICMP應用：
1、分組網間探測PING，用來測驗兩臺主機之間的連通性，PING使用了ICMP回送請求與回送回答報文，

2、traceroute

運輸層（TCP、UDP協議）

網路層為主機之間提供邏輯通信，而運輸層為應用行程之間提供端到端的邏輯通信，（真正通信的的物體是兩臺主機中的應用行程，IP協議只是把分組送到目的主機，但是還沒有交付主機中的應用行程）

運輸層的埠

TCP/IP的運輸層用一個16位埠號來標志一個埠，埠號只具有本地意義，是為了標志本計算機應用層中的各個行程在運輸層互動時的層間介面，不同計算機中，相同的埠號是沒有關聯的，16位埠號可以允許65535個不同的埠號，

根據應用程式的不同要求，運輸層需要有兩種不同的運輸協議，即面向連接的TCP和無連接的UDP， UDP直接通過埠號確定應用行程，TCP通過套接字確定行程，

① 用戶資料報協議UDP

UDP特點：
1、無連接的 ，即發送資料前不需要建立連接，因此減少了開銷和發送資料之前的時延，
2、不可靠交付，使用盡最大努力交付，
3、面向報文，應用層交給UDP多長的報文，UDP就照發送，即一次發送一個報文，既不合并，也不拆分，由應用程式選擇合適長度報文，
4、沒有擁塞控制，網路出現擁塞不會使源主機發送速率降低，適用于某些實時應用，例如IP電話、實時視頻會議等，要求源主機以恒定速率發送資料，并且允許在網路發生擁塞時丟失一些資料，
4、支持一對一、一對多、多對一、和多對多的互動通信，

當運輸層從IP層收到UDP資料報時，就根據首部中的目的埠，把UDP資料報通過相應埠上交最終的應用行程，

如果接收方UDP發現收到的報文中的目的埠號不正確（即不存在對應于該埠號的應用行程），就丟棄該報文，并由ICMP發送埠不可達差錯報文給發送方，

②傳輸控制協議TCP

TCP特點：
1、是面向連接的運輸層協議，使用前必須建立TCP連接，傳送資料完畢后，必須釋放TCP連接，
2、每條TCP連接只能有兩個端點，
3、提供可靠交付的服務， 通過TCP連接傳送的資料，無差錯、不丟失、不重復，且按順到達，
4、TCP提供全雙工通信，TCP連接的兩端都設有發送和接收快取，允許雙發任何時間發送和接收資料，

TCP連接端點（套接字）

套接字socket=（IP地址:埠號）

同一個IP地址可以有多個不同的TCP連接；
同一個埠號也可以出現在多個不同的TCP連接中：
eg：用百度瀏覽器t同時打開淘寶和京東網頁，
網頁默認埠號為80.
socket1=（淘寶IP:80），socket2=（京東IP:80）

TCP連接（三次握手）

在雙方套接字剛剛創建完成的時候，里面并沒有存放任何資料，也不知道通信的物件是誰，
請求端：只有瀏覽器器知道必要的通信資訊(物件IP，埠號等)，但這些資訊還沒有傳遞給協議堆疊，
服務端：應用程式根本不知道通信物件是誰，只有等待請求連接，

連接階段的任務：
1.請求端：把服務器的IP地址和埠號告知協議堆疊，
2.客戶端向服務器傳達開始通信的請求，

連接程序：三次握手
參考博客： https://blog.csdn.net/baiyan3212/article/details/81302448.
第一次握手： 客戶端給服務端發一個 SYN 報文，并指明客戶端的初始化序列號 ISN，此時客戶端處于 SYN_SENT 狀態，
首部的同步位SYN=1，初始序號seq=x，SYN=1的報文段不能攜帶資料，但要消耗掉一個序號，

第二次握手： 服務器收到客戶端的 SYN 報文之后，會以自己的 SYN 報文作為應答，并且也是指定了自己的初始化序列號 ISN(s)，同時會把客戶端的 ISN + 1 作為ACK 的值，表示自己已經收到了客戶端的 SYN，此時服務器處于 SYN_RCVD 的狀態，
在確認報文段中SYN=1，ACK=1，確認號ack=x+1，初始序號seq=y，此報文段也不能攜帶資料（第一次請求端將資訊發來之后，服務器端就知道了請求端的IP地址，埠號等通信控制資訊）

第三次握手： 客戶端收到 SYN 報文之后，會發送一個 ACK 報文，當然，也是一樣把服務器的 ISN + 1 作為 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處于 ESTABLISHED 狀態，服務器收到 ACK 報文之后，也處于 ESTABLISHED 狀態，此時，雙方已建立起了連接，
確認報文段ACK=1，確認號ack=y+1，序號seq=x+1（初始為seq=x，第二個報文段所以要+1），ACK報文段可以攜帶資料，不攜帶資料則不消耗序號，

ack：確認編號，即接收到的上一次遠端主機傳來的seq然后+1，再發送給遠端主機，提示遠端主機已經成功接收上一次所有資料，
ACK:確認值，為1表示確認連接，

為什么要第三次握手

第一次握手：客戶端發送網路包，服務端收到了，
這樣服務端就能得出結論：客戶端的發送能力、服務端的接收能力是正常的，
第二次握手：服務端發包，客戶端收到了，
這樣客戶端就能得出結論：服務端的接收、發送能力，客戶端的接收、發送能力是正常的，不過此時服務器并不能確認客戶端的接收能力是否正常，
第三次握手：客戶端發包，服務端收到了，

原因一：這樣服務端就能得出結論：客戶端的接收、發送能力正常，服務器自己的發送、接收能力也正常，
雙方都必須確認自己和對方的發送和接收能力都是正常的，

原因二：防止已經失效的連接請求報文段突然又傳到B，因而產生錯誤，

即：通過請求方的第二次回應報文，確保發來的連接請求是實時的請求，而不是過期的無效的請求報文，

三次握手程序中可以攜帶資料嗎

第三次握手時可以攜帶資料，但是第一、二次不行，

原因：設想這樣的場景：若第一次握手可以攜帶資料，有人要惡意攻擊服務器，則他每次都可以在第一次握手中的SYN報文中放入大量資料，會讓服務器花費很多時間、空間來處理報文，
這就是SYN攻擊： Client在短時間偽造大量不存在的ip地址，向Server不斷發送SYN包，Server則回復確認包，并等待Client確認，這些包將長時間占用未連接佇列，導致正常的SYN請求因為佇列滿被丟棄，從而引起網路擁塞甚至系統癱瘓（Dos/DDoS攻擊）

也就是說：第一次握手無法放資料，保證了服務器的安全性，而第三次握手時，已經代表成功的建立了連接，從客戶端攜帶資料到服務器也是被理解的，

TCP通信（可靠傳輸的實作）

TCP發送的報文段是交給IP層發送的，但是IP層只能提供盡最大努力服務，也就是說，TCP下面的網路所提供的的是不可靠的傳輸，因此TCP必須采用適當的措施才能使兩個運輸層之間的通信變得可靠，

在理想條件下：傳輸信道不產生差錯；不管發送方以多快的速度發送資料，接收方總是來得及處理收到的資料，
然而實際的網路中都不具備以上的條件，于是使用一些可靠傳輸協議：
當出現差錯時讓發送方重傳出現差錯的資料，同時在接收方來不及處理收到的資料時，及時告訴發送方適當降低發送資料的速度，

可靠的作業原理 ：連續ARQ協議和滑動視窗

自動重傳ARQ協議： 重傳的請求是自動進行的，接收方不需要請求發送方重傳某個出錯的分組，

連續ARQ協議：

連續ARQ協議規定，發送方的發送視窗內的分組都可以連續發送出去，而不需要等待對方的確認，發送方每收到一個確認，就把發送視窗向前滑動一個分組的位置，
接收方不必對收到的分組逐個發送確認，而是在收到幾個分組后，對按序到達的最后一個分組發送確認，

滑動視窗作業原理：

發送視窗里面的序號表示允許發送的序號，顯然，視窗越大，發送方就可以在收到對方確認之前連續發送更多的資料，在TCP連接階段，接收方就已經把自己的接受視窗值放在視窗欄位中發送給對方了，

接收方對于收到的有序分組，向發送方發送確認資訊，對于沒有按序到達的分組，先暫存在接受視窗中，
發送方根據收到的確認資訊，以及接收方視窗大小，向前移動滑動視窗或者不移動視窗，

如果發送視窗內的分組都已經發送但沒有收到確認，發送方會在一段時間過后重傳這部分資料，

發送與接收快取：

發送快取用來暫時存放：
（1）發送應用程式傳送給發送方TCP準備發送的資料
（2）TCP已經發送但尚未收到確認的資料
發送視窗只是發送快取的一部分，已被確認的資料要從發送快取中洗掉，發送應用程式必須控制寫入快取的速率，不能太快，否則發送快取就會沒有存放資料的空間，

接收快取用來暫時存放：
（1）按序到達的、但尚未被接收應用程式讀取的資料
（2）未按序到達的資料
如果收到的分組被檢測出有差錯，則要丟棄，如果接收應用程式來不及讀取收到的資料，接收快取最侄訓被填滿，使接收視窗減小到零，反之，接收視窗就可以增大，但最大不能超過接收快取的大小，

TCP流量控制

一般來收，希望的是資料傳輸的更快一些，但如果發送方把資料發送得過快，接收方就可能來不及接收，就會造成資料的丟失，流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收，利用滑動視窗機制可以很方便地在TCP連接上事項發送方的流量控制，

TCP擁塞控制

過多的資料注入到網路中，對網路中某一資源的需求超過了該資源所能提供的可用部分，網路性能就要變壞，就會造成擁塞，
例如：路由器過載，路由器沒有足夠的空間，他就會丟棄一些新到的分組，發送方多次重傳還會家中擁塞程度，

TCP的擁塞控制方法：
TCP進行擁塞控制的演算法有四種：慢開始、擁塞避免、快重傳、快恢復

擁塞控制也叫做基于視窗的擁塞控制，發送方維持一個叫做擁塞視窗的狀態量，擁塞視窗的大小取決于網路的擁塞程度，而且在動態地變化，發送方讓自己的發送視窗等于擁塞視窗，

發送方控制擁塞視窗的原則是：
只要網路沒有出現擁塞，擁塞視窗就可以再增大一些，以便把更多的分組發送出去，這樣就可以提高網路的利用率，但只要網路出現擁塞或有可能出現擁塞，就必須把擁塞視窗減小一些，以減少注入到網路中的分組數，來緩解網路擁塞，

發送方又是如何知道網路發生了擁塞呢？
當網路發生擁塞時，路由器就要丟棄分組，因此只要發送方沒有按時收到應當到達的確認報文，出現了超時，就可以判斷網路出現了擁塞，

擁塞視窗cwnd的大小變化：

1、慢開始演算法：剛開始發送資料，由于不清楚網路的負荷能力，所以由小及大逐漸增大發送視窗
（由小到大逐漸增大擁塞視窗數值），每經過一個傳輸輪次，擁塞視窗就加倍，
為了防止擁塞視窗增長過大引起網路擁塞，還設定里一個慢開始門限ssthresh.
當cwnd<ssthresh，使用慢開始演算法，
當cwnd>ssthresh，改用擁塞避免演算法，
當cwnd=ssthresh，既可以使用慢開始，也可使用擁塞避免演算法，

2、擁塞避免演算法：把擁塞視窗控制為按線性規律增長，使網路比較不容易出現擁塞， 但不能完全避免擁塞，

3、快重傳演算法：有時個別報文段會在網路中丟失，但實際網路并沒有發生擁塞，快重傳規定，發送方只要一連收到三個重復確認，就知道接收方確實沒有收到某個缺序的報文段，因而應當立即進行重傳， 這樣，發送方就不會誤認為出現了網路擁塞，增加網路吞吐量，

4、快恢復演算法： 當發送方知道只是丟失了個別的報文段，于是不啟動慢開始演算法，而是執行快恢復演算法 （快速恢復擁塞避免演算法）

TCP斷開（四次揮手）

為什么建立一個連接要三次握手，而終止需要四次呢？這是由TCP的半關閉造成的，即，TCP提供了連接的一段在結束它的發送后還能接收來自另一端資料的能力，
雙方均可主動發起揮手

假設客戶端先發起關閉請求：

第一次揮手： 客戶端發送一個FIN報文，報文中會指定一個序列號，此時客戶端處于FIN_WAIT1狀態，
即：報文段：FIN=1，seq=u， 客戶端進入FIN_WAIT1狀態，
FIN報文段即使不攜帶資料，他也消耗掉一個序號，

第二次揮手： 服務器收到FIN后，會發送ACK報文，且把客戶端序列號值+1作為ACK報文的序列號值，表示已經收到客戶端的報文了，此時服務器處于CLOSE_WAIT狀態，
即：報文段：ACK=1，ack=u+1，seq=v，服務器進入CLOSE_WAIT狀態，客戶端收到服務端的確認后，進入FIN_WAIT2狀態，等待 B發送FIN報文，
（這時的TCP連接處于半關閉狀態，即A已經沒有資料要發送了，但B若發送資料，A任然要接受，也就是說，從B到A這個方向的連接并沒有關閉，這個狀態會持續一段時間）

第三次揮手： 如果服務器也想斷開連接了，發送FIN報文，并且由于這是對于回應報文，因此確認標志ACK仍需置1，服務器端處于LAST_ACK狀態
即：報文段：ACK=1，FIN=1，ack=u+1(仍算是對seq=u的回應)，seq=w，，服務器進入LAST_ACK狀態，

第四次揮手： 客戶端收到FIN后，發送一個ACK作為應答，此時客戶端處于TIME_WAIT2狀態，而服務端收到ACK報文后，就處于CLOSED狀態.
即：報文段：ACK=1，seq=u+1(第一次為seq=u)，ack=w+1，客戶端進入TIME_WAIT狀態，此時TCP還未釋放掉，需要經過時間等待計時器設定的時間2MSL后，客戶端才進入CLOSED狀態，

斷開揮手為什么需要四次

當服務器端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴客戶端，“你發的FIN報文我收到了”，只有等我服務端所有的報文都發送完畢， 我才能發送FIN報文，

等待2MSL的意義

MSL譯為“最長報文段壽命”，是任何報文在網路上存在的最長時間，超過這個時間，報文將被丟棄，

理由一：保證客戶端發送的最后一個ACK報文段能夠到達服務端，

若客戶端發送的最后一個ACK報文段在傳輸程序丟失，服務器接受不到回應，會超時重傳一次FIN+ACK，而客戶端就能在2MSL時間內收到這個重傳的FIN+ACK，并且也重傳一次確認，重新啟動2MSL計時器，最后，雙方都正常進入到CLOSED階段

假設客戶端在TIME-WAIT階段不等待2MSL，而是在發送完ACK后直接釋放關閉，一旦這個ACK丟失的話，服務器就無法正常進入關閉連接狀態，

理由二：防止“已失效的連接請求報文段”出現在本連接中
A在發送完最后一個ACK報文段后，再經過2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網路中消失，這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段（第一次握手晚到的SYN請求報文段），

TCP粘包與拆包

參考博客鏈接: https://zhanglong.blog.csdn.net/article/details/117320585.

什么是TCP粘包？

TCP粘包是指發送方發送的若干包資料到達接收方時粘成了一包，從接收快取區來看，后一包的資料頭緊接著前一包的資料尾，出現粘包的原因是多方面的，可能來自發送方，也可能來自接收方，

1、發送方原因：

要發送的資料小于TCP發送緩沖區的大小，TCP將多次寫入緩沖區的資料一次發送出去，將會發生粘包，

TCP默認使用Nagle演算法，Nagle演算法可能造出現粘包問題，
Nagle演算法主要作用：減少網路中報文段的數量，而Nagle演算法主要做兩件事：
1、只有上一個分組得到確認，才會發送下一個分組
2、收集多個小分組，在一個確認到來時一起發送

2、接收方原因
接收資料端的應用層沒有及時讀取接收快取區中的資料，將發生粘包，

什么時候需要處理粘包現象

1、若粘包的多組資料為同一塊資料(檔案)的不同部分，則無需處理，
2、若多個分組毫無關聯，則需要處理粘包現象，

如何處理粘包現象

1、發送方
可以通過關閉Nagle演算法解決，使用TCP_NODELAY選項來關閉演算法
2、接收方
接收方沒有辦法處理粘包顯現，只能交給應用層處理
3、應用層
應用層解決粘包的方法非常簡單，不僅能解決接收方的粘包問題，還可以解決發送方的粘包問題，

解決方法：回圈處理，應用程式從接受快取中讀取分組時，讀完一條資料，就應回圈讀取下一條資料，直到所有資料都被處理完成，但如何判斷每條資料的長度呢？
1、格式化資料：每條資料都有固定格式，如開始符，結束符等，
這種方法簡單可行，但選擇開始符和結束符時一定要確保每條資料的內部不包含開始符和結束符，

2、發送長度：發送每條資料時，資料包中有專門的位置記錄該資料的長度，當應用層讀取資料包時，就可以根據資料包長度將每個分組進行拆包，
應用層處理粘包的方法叫拆包，

UDP會不會產生粘包問題？

TCP： 為了保證可靠傳輸并減少額外開銷，采用了基于流的傳輸，流傳輸不會把訊息按個傳輸，而是無保護訊息邊界的，
保護訊息邊界：指傳輸協議把資料當做一條獨立的訊息在網上傳輸，接收端一次只能接受一條獨立的訊息，

UDP： 面向訊息傳輸，有保護訊息邊界，接收方一次只接受一條獨立的訊息，因此不存在粘包問題，

應用層

運輸層為應用行程提供了端到端的通信服務，但在不同的網路應用的應用行程之間，還需要有不同的通信規則，因此還需要應用層協議來解決不同的應用問題，

域名系統DNS

用戶與互聯網上某臺主機通信時，必須要知道對方的IP地址，然而用戶很難記住長達32位的二進制主機地址，用戶層為了便于用戶記憶各種網路應用，連接在互聯網上的主機不僅有IP地址，而且還有便于用戶記憶的主機名字，域名系統能夠把互聯網上的主機名字轉換為IP地址，
域名到IP地址的決議程序是由分布在互聯網上的許多域名服務器程式共同完成的，

域名到IP地址的決議程序要點如下：當某一個應用行程需要把主機名決議為IP地址時，該應用行程就呼叫決議程式，并成為DNS的一個用戶，把待決議的域名放在DNS請求報文中，以UDP用戶資料報方式發給本地域名服務器（使用UDP是為了減少開銷）， 本地域名服務器在查找域名后，把對應的IP地址放在回答報文中回傳，應用行程獲得目的主機的IP地址后即可進行通信，若本地域名服務器不能回答該請求，則此域名服務器就暫時成為DNS中的另一個客戶，并向其他域名服務器發出查詢請求，

域名決議程序：2種查詢方式
迭代查詢：特點：本地域名服務器只與根服務器進行相互通信，
遞回查詢：特點：本地域名服務器要和其他所有有關的服務器都進行直接的兩兩通信，
具體采用哪一種方式取決于最初的查詢請求報文的設定是要求使用哪一種查詢方式，

超文本傳輸協議HTTP

HTTP協議定義了瀏覽器（即萬維網客戶行程）怎樣向萬維網服務器請求萬維網檔案，以及服務器怎樣把檔案傳送給瀏覽器， HTTP不僅傳送完成超文本跳轉所必須的資訊，而且也傳送任何可從互聯網上得到的資訊，如超文本、文本、聲音和影像等，

HTTP使用了面向連接的TCP作為運輸層協議，但是，HTTP協議本身是無連接的，也就是說，雖然HTTP使用了TCP連接，但通信的雙方在交換HTTP報文之前不需要先建立HTTP連接，

HTTP協議首先要和服務器建立TCP連接，這就需要三報文握手，當建立TCP連接的三報文握手的前兩部分完成后，萬維網客戶就把HTTP請求報文，作為建立TCP連接的三報文握手中的第三個報文的資料，發送給萬維網服務器（我們知道，在TCP連接的第一二次握手是無法攜帶資料的，第三次握手是可以攜帶資料的），服務器收到HTTP請求報文后，就把所請求的檔案作為回應報文回傳給客戶，

HTTP報文：

由于HTTP是面向文本的，因此在報文中的每一個欄位都是一些ASCII碼，因而各個欄位的長度都是不確定的，

請求報文：


回應報文：

Cookie

由于HTTP是無狀態的，即同一個客戶第二次訪問同一個服務器上的頁面時，服務器的回應與第一次被訪問時的相同， 因為服務器并不記得曾經訪問過的這個客戶，也不記得為該客戶曾經服務過多少次，HTTP的無狀態特性簡化了服務器的設計，是服務器更容易支持大量并發的HTTP請求，但在實際作業中，一些萬維網站點卻常常希望能夠識別用戶，
例如：在網上購物時，將選好的物品放入購物車，繼續瀏覽和預購其他商品，服務器必須記住用戶的身份，才能使商品放在同一個購物車，

要做到記住客戶，就可以在HTTP中使用Cookie，Cookie表示在HTTP服務器和客戶之間傳遞的狀態資訊，

作業原理：
當用戶A瀏覽某個網站時，該網站的服務器就為用戶A產生一個唯一的識別碼， 然后在后端資料庫中產生一個專案，接著在給A的HTTP回應報文中添加一個叫做Set-cookie的首部行，值為賦予該用戶的識別碼，

當A收到這個回應時，其瀏覽器就在它管理的特定Cookie檔案中添加一行，其中包括這個服務器的主機名和Set-cookie后面給出的識別碼，當A繼續瀏覽這個網站時，每發送一個HTTP請求報文，其瀏覽器就會從其Cookie檔案中提取出這個網站的識別碼，并放到HTTP請求報文的Cookie首部行中：

于是服務器就可以跟蹤這個用戶在該網站的活動，
（如果在該網站登記過密碼和郵件等資訊，只要是在同一個電腦瀏覽這個網址，就不必重新輸入資訊）

Cookie只是一個小小的文本檔案，不是計算機病毒，不是計算機可執行程式，

Session

參考文章https://www.cnblogs.com/l199616j/p/11195667.html#_label1_0.
Session是另一種記錄客戶狀態的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上，客戶端瀏覽器訪問服務器的時候，服務器把客戶端資訊以某種形式記錄在服務器上，這就是Session，客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態就可以了，

如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份，Session相當于程式在服務器上建立的一份客戶檔案，客戶來訪的時候只需要查詢客戶檔案表就可以了，

Session與Cookie比較

實作機制： Session的實作常常依賴于Cookie，通過Cookie機制回傳SessionID，

大小限制： Cookie有大小限制，并且瀏覽器對每個站點也有個數限制，session無大小限制，理論上只與服務器的記憶體大小有關，

安全性： Cookie存在安全隱患，通過攔截或本地檔案找到cookie后可以進行攻擊，而session由于保存在服務器端，相對更安全，

服務器資源消耗： Session保存在服務器端過一段時間才會消失，若session過多會增加服務器壓力，

網路安全

參考文章：https://zhanglong.blog.csdn.net/article/details/117320585.

公鑰和私鑰

公鑰和私鑰是通過一種演算法得到的一個密鑰對，公鑰是秘鑰對中公開的部分，私鑰是非公開的部分，如果用其中一個密鑰加密一段資料，必須用另一個密鑰解密，比如用公鑰加密資料就必須用私鑰解密，如果用私鑰加密也必須用公鑰解密，否則解密將不會成功，

原則：公鑰公開，私鑰只有自己擁有，

對稱加密與非對稱加密

對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；

? 非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發布，但私鑰只有自己知道，發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密資訊后，使用自己的私鑰進行解密，

? 由于非對稱加密的方式不需要發送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送訊息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發送出去，

總結一下：通過非對稱加密的方式把秘鑰發送過去，接下來用這個秘鑰一直進行對稱加密，

即：第一次通信采用非對稱加密，接下來的通信采用對稱加密

RSA加密演算法

參考文章： https://www.cnblogs.com/soldierback/p/11601824.html.
RSA演算法是一種非對稱的加密演算法，它通常是先生成一對RSA密鑰，其中之一是保密密鑰（私鑰），由用戶保存；另一個為公開密鑰（公鑰），可對外公開；要加密傳輸內容時，比如A要給B傳輸資訊，此時A先用B的公鑰將內容加密后傳輸，B收到A傳輸過來的資訊后用自己的私鑰解密.

該程序中，只要B不泄露自己的私鑰，那么就算第三方截取到了該資訊，沒有B的私鑰也無法解密獲得內容資訊.
RSA演算法的安全性依賴于大數分解，計算兩個大素數的乘積很容易，但是反過來由該乘積分解成兩個素數相乘，如果該乘積夠大的話，分解的難度是極其大的

HTTPS

當萬維網能夠提供網上購物時，安全問題就來了，客戶要確保服務器屬于真正的銷售商、客戶與服務器要確保諸如信用卡號之類的敏感資訊不會被冒充者竊聽等等問題，

像這些安全服務，需要使用運輸層的安全協議，其中一個就是SSL（安全套接字層）

SSL

SSL作用在端系統應用層的HTTP和運輸層之間，在TCP之上建立起一個安全通道，為通過TCP傳輸的應用層資料提供保障，

應用層使用SSL最多的就是HTTP，

當使用普通不加密的瀏覽器查看網頁時，HTTP就直接使用TCP連接，這時SSL不起作用，但使用信用開進行網上支付，要鍵入信用卡密碼時，就需要使用安全瀏覽器，這時應用程式HTTP就呼叫SSL對整個網頁進行加密，網址欄中，http變成了https，s代表security，表明現在使用的是提供安全服務的HTTP協議，

發送方：SSL從SSL套接字接收應用層資料，對資料加密，然后把加密的資料送往TCP套接字；
接收方： SSL從TCP套接字讀取資料，解密后，通過SSL套接字把資料交給應用層，

作業流程：

HTTPS為什么安全

1、混合加密
作用：防竊聽

混合加密：即同時采用公鑰和私鑰加密，更安全，更高效，更不易被破解，

HTTPS采用對稱加密和非對稱加密結合的混合加密方式
在通信建立前采用非對稱加密的方式交換秘鑰，后續就不在使用非對稱加密，
在通信程序中全部使用對稱加密的會話秘鑰方式，加密明文資料，

2.、摘要演算法
作用：防止資料被篡改，

摘要演算法：實作資料完整性，能夠為資料生成獨一無二的指紋，指紋用于校驗資料的完整性，解決了被篡改的風險，

程序
1、客戶端發送明文前，會通過摘要演算法算出明文的指紋，發送時明文和指紋一同加密，發送給服務器，

2、服務器解密后，用相同的摘要演算法算出發送過來的明文，通過比較客戶端攜帶的指紋和當前指紋做比較，若相同，則說明資料是完整的，

3.、數字證書
作用：解決身份認證問題，

程序：借助第三方權威機構CA（數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構辦法）中，只要證書是可信的，公鑰就是可信的，

HTTP與HTTPS區別

埠不同： HTTP與HTTPS使用不同的連接方式，用的埠也不一樣，前者是80，后者是443；

資源消耗： 和HTTP通信相比，HTTPS通信會由于加減密處理消耗更多的CPU和記憶體資源；

開銷： HTTPS通信需要證書，而證書一般需要向認證機構購買；