[計算機網絡] 應用層知識點彙總

自問自查

1. http 封包結構 請求行 響應行
 2. 常見的封包首部字段
 3. http 1.1,2.0 對比 1.0
 4. https   過程   怎麼驗證證書正确性的
 5. http請求方法
 6. 域名,主機名?
 7. DNS的優缺點
 8. get post的差別
 9. 狀态碼
 10.Cookie ,Session,token
 11.重定向和轉發
 
  
           

文章目錄

• • 自問自查
  • http封包
  • • http首部
  • http 1.1,2.0 對比 1.0
  • • http1.0
    • http2.0:
  • https
  • http請求方法
  • 域名,主機名?
  • DNS的優缺點
  • get post的差別
  • 狀态碼
  • Cookie ,Session,token
  • 重定向和轉發
  • 自問自查

http封包

http首部

http 首部字段:

請求頭:

If-Modified-Since，請求的資源在指定日期後發生了更新伺服器才接受請求傳回200

如果沒修改 就傳回 304未修改

if- Match:

If-None-Match, 隻有當If-Match的字段值跟請求資源的ETag值不比對時伺服器才接受請求，利用它可以擷取最新的資源。

Connection: Keep-Alive 保持連接配接

Cookie

host:主機

響應頭:

Content-Type, 實體主體内對象的媒體類型 如Content-Type: text/html; charset=UTF-8。

last-modified : 最後修改

Set-Cookie:XXXXXXXXXXXXX“

http 1.1,2.0 對比 1.0

http1.0

HTTP/1.1預設持久連接配接

HTTP/1.0會斷開，除非設定Connection: keep-alive

在HTTP1.0中主要使用header裡的If-Modified-Since,Expires來做為緩存判斷的标準

HTTP1.1則引入了更多的緩存控制政策例如Entity tag

If-None-Match

http2.0:

HTTP1.x有以下幾個主要缺點：

1.

HTTP/1.0一次隻允許在一個TCP連接配接上發起一個請求，是以用戶端在需要發起多次請求時，通常會采用建立多連接配接來減少延遲。

2.

單向請求，隻能由用戶端發起。

3.

請求封包與響應封包首部資訊備援量大。

4.

資料未壓縮，導緻資料的傳輸量大。

SPDY目标是優化HTTP協定的性能，通過壓縮、多路複用和優先級等技術，縮短網頁的加載時間并提高安全性。SPDY并不是一種用于替代HTTP的協定，而是對HTTP協定的增強。

HTTP2.0特點:

二進制傳輸

HTTP2.0中所有加強性能的核心是二進制傳輸，在HTTP1.x中，我們是通過文本的方式傳輸資料。基于文本的方式傳輸資料存在很多缺陷，文本的表現形式有多樣性，是以要做到健壯性考慮的場景必然有很多，但是二進制則不同，隻有0和1的組合，是以選擇了二進制傳輸，實作友善且健壯。

在HTTP2.0中引入了新的編碼機制，所有傳輸的資料都會被分割，并采用二進制格式編碼

為了保證HTTP不受影響，那就需要在應用層（HTTP2.0）和傳輸層（TCP or UDP）之間增加一個二進制分幀層。在二進制分幀層上，HTTP2.0會将所有傳輸的資訊分為更小的消息和幀，并采用二進制格式編碼，其中HTTP1.x的首部資訊會被封裝到Headers幀，而Request Body則封裝到Data幀。

多路複用

在HTTP1.0中，當頁面需要請求很多資源的時候，隊頭阻塞（Head of line blocking）會導緻在達到最大請求時，資源需要等待其他資源請求完成後才能繼續發送。

HTTP2.0中，有兩個概念非常重要：幀（frame）和流（stream）。

幀是最小的資料機關，每個幀會辨別出該幀屬于哪個流，流是多個幀組成的資料流。

所謂多路複用，即在一個TCP連接配接中存在多個流，即可以同時發送多個請求，對端可以通過幀中的表示知道該幀屬于哪個請求。在用戶端，這些幀亂序發送，到對端後再根據每個幀首部的流辨別符重新組裝。通過該技術，可以避免HTTP舊版本的隊頭阻塞問題，極大提高傳輸性能。

Header壓縮

在HTTP1.0中，我們使用文本的形式傳輸header，在header中攜帶cookie的話，每次都需要重複傳輸幾百到幾千的位元組，這着實是一筆不小的開銷。

在HTTP2.0中，我們使用了HPACK（HTTP2頭部壓縮算法）壓縮格式對傳輸的header進行編碼，減少了header的大小。并在兩端維護了索引表，用于記錄出現過的header，後面在傳輸過程中就可以傳輸已經記錄過的header的鍵名，對端收到資料後就可以通過鍵名找到對應的值。

伺服器Push

在HTTP2.0中，服務端可以在用戶端某個請求後，主動推送其他資源。

可以想象一下，某些資源用戶端是一定會請求的，這時就可以采取服務端push的技術，提前給用戶端推送必要的資源，就可以相對減少一點延遲時間。在浏覽器相容的情況下也可以使用prefetch。

https

一對公鑰和私鑰是算法算出來的,不能随便定義

使用非對稱加密傳輸随機碼,使用随機碼進行對稱加密既保證了安全性又減少了計算量

SSL的證書一般都是收費的

一個有效、可信的 SSL 數字證書包括一個公共密鑰和一個私用密鑰。

浏覽器如何驗證證書:

浏覽器驗證此證書中的域是否和通路的域一緻（比如使用者通路https://mail.google.com/時，浏覽器驗證伺服器發送過來的SSL證書的公鑰中的域是否為mail.google.com或*.google.com）并沒有過期

正規的CA機構的根證書都會被植入到各大浏覽器中，如果浏覽器發現SSL證書不是由受信任的CA機構頒發的，則會有安全警告發出，建議關閉此網頁，并且不要繼續浏覽該網站。例如非正規CA機構頒發的自簽名SSL證書就會出現這種情況。

非對稱加密RSA:

http請求方法

GET:擷取資源

POST:傳輸實體主體

PUT:傳輸檔案

HEAD:擷取封包首部

DELETE:删除檔案

OPTIONS：詢問支援的方法

TRACE：追蹤路徑

CONNECT：要求用隧道協定連接配接代理

域名,主機名?

https://blog.csdn.net/m0_37581397/article/details/83184979

http://mail.163.com/index.html

1）http://:這個是協定，也就是HTTP超文本傳輸協定，也就是網頁在網上傳輸的協定。

2）mail：這個是伺服器名，代表着是一個郵箱伺服器，是以是mail。 (提供郵箱服務的機器就叫 mail)

3）163.com：這個是域名，是用來定位網站的獨一無二的名字。

4）mail.163.com：這個是主機名（網站名），由伺服器名+域名組成。

5）/：這個是根目錄，也就是說，通過網站名找到伺服器，然後在伺服器存放網頁的根目錄

6）index.html：這個是根目錄下的預設網頁（當然，163的預設網頁是不是這個我不知道，隻是大部分的預設網頁，都是index.html）。

7）http://mail.163.com/index.html：這個叫做URL，統一資源定位符，全球性位址，用于定位網上的資源。

想建立一個www伺服器，是以www.163.com有了，又想整個郵箱伺服器，ok，mail.163.com有了

域名還分級，從後往前級别依次降低，sina.com.cn中，cn是頂級域名，表示中國，com是二級域名，表示商業機構（commercial），sina是三級域名，一般用自己的名字。

DNS的優缺點

浏覽器緩存 – 浏覽器會緩存DNS記錄一段時間。 有趣的是,作業系統沒有告訴浏覽器儲存DNS記錄的時間,這樣不同浏覽器會儲存個自固定的一個時間(2分鐘到30分鐘不等)。

查完浏覽器之後再查host

DNS的端口号是53

一般用UDP傳輸 因為DNS伺服器給很多主機服務 TCP負擔太大

主DNS伺服器和從DNS伺服器是用TCP 因為他們要經常連接配接

DNS缺點:

不能夠按照Web伺服器的處理能力配置設定負載。DNS負載均衡采用的是簡單的輪循負載算法，不能區分伺服器之間的差異

沒有考慮高可用,某台伺服器故障,還會将請求送到這裡

https://blog.csdn.net/weibo1230123/article/details/82946179

get post的差別

GET幂等/POST不幂等

幂等是指同一個請求方法執行多次和僅執行一次的效果完全相同

與GET不同的是，PUT請求是向伺服器端發送資料的，進而改變資訊，該請求就像資料庫的update操作一樣，用來修改資料的内容，但是不會增加資料的種類等，也就是說無論進行多少次PUT操作，其結果并沒有不同。

POST請求同PUT請求類似，都是向伺服器端發送資料的，但是該請求會改變資料的種類等資源，就像資料庫的insert操作一樣，會建立新的内容。幾乎目前所有的送出操作都是用POST請求的

get請求可以被緩存和儲存 post不可以

GET 請求保留在浏覽器曆史記錄中

GET 請求可被收藏為書簽

狀态碼

502已經與後端建立了連接配接，從上遊伺服器接收到無效的響應； 504與後端連接配接未建立，逾時。

· 400 bad request，請求封包存在文法錯誤

· 401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證資訊(賬号密碼錯誤)

· 403 forbidden，表示對請求資源的通路被伺服器拒絕

· 404 not found，表示在伺服器上沒有找到請求的資源

301 永久重定向 302 臨時重定向

307 臨時重定向 http 307和302的差別在于：307要求用戶端不改變原先的請求方法，對在Location頭部中規定的URI進行通路。對于302，很多用戶端的實作是，直接使用GET方式通路重定向位址。 對于 GET 請求來說，兩種情況沒有差別。

304 未修改

預設端口:

HTTP 80 ; SMTP 25; POP3 110; FTP 21 20; TELNET 23

ftp 21端口是一個指令端口20是一個資料端口

Cookie ,Session,token

cookie和session的差別如下：

1、session儲存在伺服器，用戶端不知道其中的資訊；cookie儲存在用戶端，用戶端能夠知道其中的資訊。

2、session中儲存的是對象，cookie中儲存的是字元串。

3、session需要借助cookie才能正常工作。如果用戶端完全禁止cookie，session将失效。

session針對使用者 cookic針對主機

Cookie通過在用戶端記錄資訊确定使用者身份，Session通過在伺服器端記錄資訊确定使用者身份。

session需要存儲在服務端(占用資源),而token不需要,session把鑰匙給用戶端,token把鑰匙和鎖都給用戶端,兩者都存在生存時間。

前面是鑰匙後面的簽名是鎖 發給服務端驗證是否正确

對伺服器程式來說，究竟是有狀态服務，還是無狀态服務，其判斷依舊是指兩個來自相同發起者的請求在伺服器端是否具備上下文關系。如果是狀态化請求，那麼伺服器端一般都要儲存請求的相關資訊，每個請求可以預設地使用以前的請求資訊。而對于無狀态請求，伺服器端所能夠處理的過程必須全部來自于請求所攜帶的資訊，以及其他伺服器端自身所儲存的、并且可以被所有請求所使用的公共資訊。

重定向和轉發

轉發是伺服器行為，重定向是用戶端行為

重定向，其實是兩次request,

第一次，用戶端request A,伺服器響應，并response回來，告訴浏覽器，你應該去B。這個時候IE可以看到位址變了，而且曆史的回退按鈕也亮了。重定向可以通路自己web應用以外的資源。在重定向的過程中，傳輸的資訊會被丢失。

請求轉發是伺服器内部把對一個request/response的處理權，移交給另外一個

對于用戶端而言，它隻知道自己最早請求的那個A，而不知道中間的B，甚至C、D。 傳輸的資訊不會丢失。

文章目錄

• • 自問自查
  • http封包
  • • http首部
  • http 1.1,2.0 對比 1.0
  • • http1.0
    • http2.0:
  • https
  • http請求方法
  • 域名,主機名?
  • DNS的優缺點
  • get post的差別
  • 狀态碼
  • Cookie ,Session,token
  • 重定向和轉發
  • 自問自查

自問自查

1. http 封包結構 請求行 響應行
 2. 常見的封包首部字段
 3. http 1.1,2.0 對比 1.0
 4. https    過程   怎麼驗證證書正确性的
 5. http請求方法
 6. 域名,主機名?
 7. DNS的優缺點
 8. get post的差別
 9. 狀态碼
 10.Cookie ,Session,token
 11.重定向和轉發