網絡基礎總結

1、網絡分層
    

TCP的四層：
    1、應用層： 規定向用戶提供應用服務時通訊協議。 如DNS
    2、傳輸層： 提供處於網路鏈接中兩臺計算機之間的數據傳輸所使用的協議。在傳輸層有兩個性質不一樣的協議TCP和UDP
    3、網絡層： 規定了數據經過怎麼樣的傳輸路線到對方計算機傳送給對方。如IP協議
    4、鏈路層： 用來處理鏈接網絡硬件的部分，包括操做系統、硬件設備的驅動、網卡等

2、TCP
1.簡介
    TCP是傳輸控制協議，基於TCP的應用層有HTTP、SMTP、FTP協議等
2.特色
 面向鏈接、面向字節流、全雙共通道、可靠。
      面向鏈接：使用TCP傳輸數據前，必須先創建TCP鏈接，傳輸完成後在釋放鏈接
      全雙共通道：創建TCP鏈接後，通訊雙方都能發送數據
      可靠：經過TCP鏈接傳送的數據：不丟失、無差錯、不重複、按序到達
      面向字節流：數據以流的形式進行傳輸
    3.優缺點
      優勢：數據傳輸可靠
      缺點：效率慢（因需創建鏈接、發送確認包等）
    4.創建鏈接  3次握手
      第一次握手：客戶端向服務器發送一個鏈接請求的報文段。報文段信息包括：同步標誌位(SYN)設爲一、隨機選擇一個起始序號(seq)爲x、不攜帶數據。客戶端進入同步已發送狀態(SYN_SEND),等待服務器的確認
      第二次握手：服務器收到請求鏈接報文段後，若贊成創建鏈接，則向客戶端發回鏈接確認的報文段。報文段信息包括：同步標誌位(SYN)設爲一、確認標記位(ACK)爲一、隨機選擇一個起始序號(seq)爲y、確認號字段(ack)爲x+一、不攜帶數據。服務器進入同步已接受狀態(SYN_RCVD)
      第三次握手：客戶端收到確認報文字段後，向服務器再次發出鏈接確認報文段。報文段信息包括：確認標記位(ACK)爲一、序號(seq)爲x+一、確認號字段(ack)爲y+一、可攜帶數據。客戶端、服務段都進如已建立狀態，可開始發送數據

    注意：成功進行TCP的三次握手後，就創建一條TCP鏈接，可傳送應用層數據。
        由於TCP提供的全雙工通訊，故通訊雙發的應用進程在任什麼時候候都能發送數據。三次握手期間，任何一次未收到對面的回覆，則都會重發。
    5.爲何TCP創建鏈接須要三次握手？
        防止服務器端因接收了早已失效的鏈接請求報文，從而一隻等待客戶端請求，最終致使造成死鎖、浪費資源。
        描述以下：
            a.客戶端發出的第一個鏈接請求報文段無丟失，而是在某個網絡結點長時間滯留了，致使延誤到鏈接釋放後的某個時間纔到達服務器。
            b.致使延誤到鏈接釋放後的某個時間纔到達服務器
            c.這是一個早已失效的報文段，可是服務器不知道，服務器收到此失效的鏈接請求報文段後，就誤覺得是客戶端再次發出的一個新的請求，因而向客戶端
              發出了確認報文段，贊成創建TCP鏈接
            d.假設不採用「三次握手」，即服務器發出確認報文段後，TCP鏈接就創建了，但因爲客戶端並沒有發出創建鏈接的請求，所以不會向服務器發送數據，因對                於客戶端來講，該報文已失效了，可是服務器卻覺得新的TCP鏈接已創建，因而一直等待客戶端發送數據，即死鎖狀態
            e.創建鏈接= 採用「三次握手」，即關鍵是第三次握手。
            f.在上面的狀況，客戶端不會向服務器的確認報文信息，再次發出確認。服務器因爲收不到客戶端的確認信息，即知道客戶端並沒有要求創建TCP鏈接，故                服務器不會一直等待客戶端發送數據，即不會造成死鎖狀態
        其餘的：SYN洪泛濫：服務器的TCP資源分配時刻=完成第二次握手時，而客戶端的TCP資源分配時刻 = 完成第三次握手時，這使得服務器易於受到SYN洪泛攻          擊，即同時多個客戶端發起鏈接請求，從而需進行多個請求的TCP鏈接資源分配。
    6.斷開須要四次揮手
        在通訊結束後，雙方均可以釋放鏈接，共需四次握手。
        釋放TCP鏈接前。TCP客戶端、服務器都處於已建立狀態（ESTABLISHED），直到客戶端主動關閉TCP鏈接
        第一次揮手：客戶端向服務器發起一個鏈接釋放的報文段（中止在發送數據）。報文段信息：終止控制(FIN)設爲一、報文段序號，設爲前面傳送數據最後一個            字節的序號加1（seq = u）,可攜帶數據（FIN = 1的報文幾時不攜帶數據也消耗一個序號）。客戶端進入終止等待1狀態。（FIN-WAIT-1）
        第二次握手：服務器收到鏈接釋放報文段後，則向客戶端發回鏈接釋放確認的報文段。報文段信息：確認標記位設爲1: ACK=一、報文段序號，設爲前面傳送            數據最後一個字節的序號加1（seq = v），確認號字段設爲：ack= u+1。服務器進入關閉等待狀態（CLOSE-WAIT）,客戶端收到服務器的確認後，進入            終止等待2狀態（FIN-WAIT-2），等待服務器發出釋放鏈接請求。至此，客戶端->服務器的TCP鏈接已斷開，即TCP鏈接處於半關閉的狀態，即客戶端->            服務器斷開，但服務器->客戶端未斷開
        第三次握手：若服務器已無要向客戶端發送數據，則發出釋放鏈接的報文段。報文段信息：終止控制(FIN)設爲一、確認標記位設爲1：ACK=1，報文段序號，            設爲（seq = w）,重複上次已發送的確認號字段設爲：ack = u+一、可攜帶數據（FIN = 1的報文即便不攜帶數據也消耗一個序號）。服務器進入最後確            認狀態（LAST-ACK）
        第四次握手：客戶端收到鏈接釋放報文段後，則向服務器發回鏈接釋放確認的報文段。報文段信息：確認標記位設爲1:ACK=一、                                報文段序號：seq = u + 一、確認號字段爲：ack = w + 一、可攜帶數據（FIN = 1的報文幾時不攜帶數據也消耗一個序號）。 客戶端進入等待時間狀            態（TIME-WAIT），服務器進入關閉狀態（COLSE），此時TCP鏈接還未釋放，必須通過時間等待計時器設置的時間2MSL後，客戶端才進入鏈接關閉狀態            （CLOSED），即服務器進入關閉狀態比客戶端要早一些。

    7.爲何TCP釋放鏈接需4次揮手？
        爲了保證通訊雙方都能通知對方。需釋放和斷開鏈接。
        當主機1發出「釋放鏈接請求」、主機2返回「確認釋放鏈接」信息時，只表示主機1已無數據要發送到主機2，但主機2仍是能夠發送數據給主機1，主機1仍是能夠          接受主機2的數據，即單向斷開    
        當主機2也發送了「釋放鏈接請求」、主機1返回「確認釋放鏈接」信息時，表示主機2已無數據要發送到主機1，此時雙發都沒法通訊，即TCP鏈接纔算真正釋放          （雙向）

    八、爲何客戶端關閉鏈接前要等待2MSL時間？
        即TIME-WAIT狀態的做用是什麼？MSL = 最長報文壽命（Maximum Segment Lifttime）
        緣由1:爲了保證客戶端發送的最後一個請求鏈接釋放確認報文能到達服務器，從而使得服務器能正常釋放鏈接。解析：以下：
             a.客戶端發送的最後一個鏈接釋放確認報文可能會丟失，當服務器收不到最後一個鏈接釋放確認報文時，則不會進入關閉狀態，但會超時重發，鏈接釋放報文。    
             b.假設：客戶端不等待2MSL時間就直接進行關閉狀態（CLOSED），當最後一個鏈接釋放確認報文丟失、服務器重發鏈接釋放報文時，客戶端則沒法接收到服務器從新發送的鏈接釋放報文時，客戶端則沒法接收到服務器從新發送的鏈接釋放報文，所以也不會發送鏈接釋放確認報文段，最終致使服務沒法進入關閉狀態（CLOSED）。
            c。客戶端發送最後一個鏈接釋放確認後哦，先等待2MSL時間，在進入關閉狀態（CLOSE），此時客戶端則接收到服務器從新發送的鏈接釋放報文，從而發送鏈接釋放確認報文段，會從新啓動2MSL計時器，使得服務器能正常進入關閉狀態（CLOSED）
        緣由2:防止上文提到的早已失效的鏈接請求報文出如今本鏈接中，客戶端發送了最後一個鏈接釋放請求確認報文後，再通過2MSL時間，則可以使本鏈接持續時間內所產生的全部報文段都從網絡中消失。即在下一個新的鏈接中就不會出現早已失效的鏈接請求報文。、

    9.TCP無差錯傳輸？
        相對於UDP，TCP的傳輸是可靠的、無差錯的。
        對於發送端：每收到一個確認幀，發送窗口就向前滑動一個幀的距離，當發送窗口內無可發送的幀時（即窗口內的幀所有是已發送但未收到確認的幀），發送方就會中止發送，直到收到接收方發送的確認幀使窗口移動，窗口內有能夠發送的幀，以後才能夠繼續發送。
        對於接收端：當收到數據幀後，將串口向前移動一個位置，並返回確認幀，若收到的數據落在窗口以後，則一概丟棄。

        發送窗口：定義：任意時刻，發送方維持的一組連續的、容許發送幀的幀序號。做用：對發送方進行流量控制。
        接收串口：定義：任意時刻，接收方維持的一組連續的、容許接收幀的幀序號。做用：控制可接收哪些數據，不可接收哪些數據幀；接收方只有當收到的數據的序號落入接收窗口內才容許將該數據幀手下；不然，一概丟棄。

    10.TCP和UDP的區別
        TCP：面向鏈接、可靠、字節流（傳輸形式）、傳輸速率慢、所需資源多、要求通訊數據可靠，首部字節在20-60
        UPD：無鏈接、不可靠、數據報文段（傳輸形式）、傳輸速率快、所需資源少、要求通訊速度快，首部字8個字節（由4個字段組成）

2、UDP
    1.面向無鏈接
    UDP是不須要和 TCP 同樣在發送數據前進行三次握手創建鏈接的，想發數據就能夠開始發送了。而且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操做。
    具體來講： 

    a.在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增長一個 UDP 頭標識下是 UDP 協議，而後就傳遞給網絡層了

    b.在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操做

   2.不可靠性
      a.不可靠性體如今無鏈接上，通訊都不須要創建鏈接，想發就發。
     b.收到什麼數據就傳遞什麼數據，而且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。

     c.網絡環境時好時壞，可是 UDP 由於沒有擁塞控制，一直會以恆定的速度發送數據。即便網絡條件很差，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件很差的狀況下可能會致使丟包，可是優勢也很明顯，在某些實時性要求高的場景（好比電話會議）就須要使用 UDP 而不是 TCP。

   3.高效
    UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。
    UDP 頭部包含了如下幾個數據
兩個十六位的端口號，分別爲源端口（可選字段）和目標端口
整個數據報文的長度
整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤
    4.傳輸方式
        UDP 不止支持一對一的傳輸方式，一樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

3、HTTP
    1.簡介和特色
        http：超文本傳輸協議，完成從客戶端到服務器等一些系列運做流程。web是創建在http協議上的通訊。
        特色：a.http是不保存狀態的協議，既無狀態協議。協議自己對於請求或響應之間的通訊狀態不進行保存，所以鏈接雙方不能知曉對方當前的身份和狀態。這也是Cookie技術產生的重要緣由之一：客戶端的狀態管理。瀏覽器會根據從服務器端發送的響應報文內 Set-Cookie 首部字段信息自動保持 Cookie。而每次客戶端發送 HTTP 請求，都會在請求報文中攜帶 Cookie，做爲服務端識別客戶端身份狀態的標識。
             b.無鏈接，即交換http報文前，不須要創建HTTP鏈接
        http協議是TCP/IP協議的一個子集.http採用TCP做爲運輸層協議。
     2.http請求報文。
        http的請求報文有請求行、請求頭、請求體組成
        請求行： 聲明請求方法、主機域名、路徑資源、協議版本
        請求頭：聲明客戶端、服務器、等報文的部分信息
        請求體：存放需發送的數據信息
        報文結構以下：

    2.1請求行
        請求行： 聲明請求方法、主機域名、路徑資源、協議版本
        注意空格不能省略
    請求方法：
        GET：請求讀取url標誌的信息
        POST：爲服務器添加信息
        HEAD：請求讀取URL標誌信息的首部信息
        PUT：指定的URL下添加（存儲）一個文檔
        DELETE：刪除指定URL所標誌信息
        TRACE：用於進行環回測試的請求豹紋
        CONNECT：用於代理服務器
        OPTION： 請求選項信息
    請求路徑（URL的地址部分）
        定義：統一資源定位符，
        做用：表示資源位置
        組成：協議：// 主機：端口/路徑
    協議版本：
        做用：定義http的版本號
        常見的有HTTP HTTP1.0 HTTP1.1 HTTP2.0 HTTP3.0
請求地址址:Request URL:https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/img/camera_new_5606e8f.png
請求方法 Request Method:GET
遠程地址:Remote Address:14.152.86.32:443
狀態碼:Status Code：304
版本:HTTP/2.0
Referrer 政策 Referrer Policy:unsafe-url
    2.1請求頭
        做用：聲明客戶端、服務器的報文的部分信息
        使用方式：字段名：值
        經常使用的請求和響應報文的通用Header
通用字段 做用
Content-Type   請求體/響應體的類型。如text/plain、application/json
Accept  說明接收的類型，能夠多個值。用,(半角號)分開
Content-Length  請求/響應體的長度，單位字節
Cache-Control  取值通常爲no-cache 或 max-age=xx， xx爲整數，表示該資源緩存有效期（秒）
Ttag  給當前資源的標識別，和last-nodified、If-None-Match、If-Modified-Since配合，用於緩存控制
Connection 瀏覽器想要優先使用的鏈接類型，好比 keep-alive
Date 建立報文時間
Transfer-Encoding 傳輸編碼方式
Upgrade 要求客戶端升級協議
    常見的請求頭
請求首部 做用
Authorization  用於設置身份認證信息
Accept-Encoding 能正確接收的編碼格式列表
Host 服務器的域名和端口號
If-Modified-Since  值爲上一次服務器返回的Last-modified值，用於確認某個資源是否被更改過，沒有更改返回 304（比較時間）就重緩存裏面拿
If-None-Match  值爲上一次服務器返回的Etag值，通常會和if-modified-since一塊兒出現
User-Agent 客戶端信息
Cookie
已有的cookie
Referer  表示請求引用自哪一個地址，好比你從頁面A跳轉到頁面B時，值爲頁面A的地址。
Host  請求端口
TE
傳輸編碼方式
Accept-Encoding 能正確接收的編碼格式列表
Accept-Language
能正確接收的語言列表

Host: ss1.bdstatic.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: image/webp,/
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://ss1.bdstatic.com/5eN1bjq8AAUYm2zgoY3K/r/www/cache/static/protocol/https/soutu/css/soutu.css
Connection: keep-alive
If-Modified-Since: Mon, 07 Nov 2016 07:51:11 GMT
If-None-Match: "287-540b1498e39c0"
Cache-Control: max-age=0
TE: Trailers
    2.3請求體                    
    做用：存放 需發送給服務器的數據信息
    注意： get無請求體

    3.http響應報文
        響應報文包括：狀態行、響應頭、響應體
        狀態行： 聲明協議版本、狀態碼描述
        響應體：聲明客戶端、服務器報文部分信息
        響應體： 存放需發送的數據信息

    3.1狀態行
        組成： 協議版本、狀態碼、狀態信息組成 注意：空格不能省 和（\r\n）
        狀態碼後面單獨講
    3.2響應頭
        做用：聲明客戶端、服務器報文的部分信息
        使用方式： header：value
響應首部 做用
Date  服務器日期
Last-modified  資源最後被修改時間
ETag 資源標識
Transfer-Encoding  取值通常爲chunked，出如今Content-Lenght不能肯定的狀況下，表示服務器不知道響應版本的數據大小，通常同時還會出現Content-Encoding響應頭
Set-cookie  設置cookie
Location  重定向到另一個URL，如輸入瀏覽器就輸入baidu.com回車，會自動跳轉到https://www.baidu.com.就是經過這個響應頭控制的
Server  後臺服務器

    4.http狀態碼
        1xx：表示信息通知，如請求收到了或正在處理
        2xx：表示成功，如接收或者直到了
        3xx：表示重定向，如要完成請求還必須採起進一步行動
        4xx：表示客戶端端錯誤，請求包含語法錯誤/沒法實現
        5xx：表示服務器，服務器不能實現一種明顯無效的請求
        
        200->ok
          請求已成功，請求所但願的響應頭或數據體將隨此響應返回。實際的響應將取決於所使用的請求方法。在GET請求中，響應將包含與請求的資源相對應的實體。在POST請求中，響應將包含描述或操做結果的實體。
        202-> Accepted
          服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止。    
        301 -> Moved Permanently 請求的資源已被永久移動到新的位置
           被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。[19]除非額外指定，不然這個響應也是可緩存的。 新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。 若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求獲得了一個301響應的話，接下來的重定向請求將會變成GET方式。
         302 -> Found 請求的資源被臨時移動到新的位置
            要求客戶端執行臨時重定向（原始描述短語爲「Moved Temporarily」）。[20]因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。 新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。 若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。 注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。[21]所以狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。
        304 -> Not Modified
            表示資源在由請求頭中的If-Modified-Since或If-None-Match參數指定的這一版本以後，不曾被修改。在這種狀況下，因爲客戶端仍然具備之前下載的副本，所以不須要從新傳輸資源。
        400 -> Bad Request
            明顯的客戶端錯誤（例如，格式錯誤的請求語法，太大的大小，無效的請求消息或欺騙性路由請求），服務器不能或不會處理該請求。
        401 -> Unauthorized 請求須要驗證用戶
        403 -> Forbidden 不容許訪問該地址
            HTTP 403 服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個HEAD請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。
        404 -> not Found 
            求失敗，請求所但願獲得的資源未被在服務器上發現，但容許用戶的後續請求。[35]沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。 
        408 -> Request Timeout 請求超時
            客戶端沒有在服務器預備等待的時間內完成一個請求的發送，客戶端能夠隨時再次提交這一請求而無需進行任何更改
        500 -> 服務端內部錯誤       
            通用錯誤消息，服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。沒有給出具體錯誤信息。 
        502 -> bad gateway
            網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

    5.http2.0 /http3.0         http2.0