Http協議狀態碼

1**：信息類狀態碼，表示接受的請求正在處理

臨時響應并需要請求者繼續執行操作的狀態代碼

2**：成功狀態碼，表示請求正常處理完畢

3**：重定向，表示要完成請求，需要進一步操作。

4**：客戶端錯誤，請求可能出錯，妨礙了服務器的處理

5**：服務器端本身錯誤，

常見狀態碼：

200：請求被成功處理,請求所希望的響應頭或者數據體將隨此響應返回。

204:服務器成功處理請求，但不返回任何實體內容

206:服務器已經成功處理部分get請求，類似于迅雷講一個大文件分解為多個下載段同時下載

?

301: 永久性重定向，可緩存

302:臨時性重定向，可緩存

303: 對應當前請求的響應可以在另一個 URI 上被找到，而且客戶端應當采用 GET 的方式訪問那個資源。這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。當然，第二個請求（重定向）可能被緩存。　　新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。　　注意：許多 HTTP/1.1 版以前的瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規范要求客戶端處理303響應時應當做的。304: 如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）并沒有改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭后的第一個空行結尾。　　該響應必須包含以下的頭信息：Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵守這些規則，那么代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制將會正常工作。ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。　　假如本響應請求使用了強緩存驗證，那么本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。　　假如某個304響應指明了當前某個實體沒有緩存，那么緩存系統必須忽視這個響應，并且重復發送不包含限制條件的請求。　　假如接收到一個要求更新某個緩存條目的304響應，那么緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值。307: 請求的資源現在臨時從不同的URI 響應請求。由于這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。　　新的臨時性的URI 應當在響應的 Location 域中返回。除非這是一個HEAD 請求，否則響應的實體中應當包含指向新的URI 的超鏈接及簡短說明。因為部分瀏覽器不能識別307響應，因此需要添加上述必要信息以便用戶能夠理解并向新的 URI 發出訪問請求。　　如果這不是一個GET 或者 HEAD 請求，那么瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

400:1.語義有誤當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重復提交這個請求。2.參數錯誤

401: 當前請求需要用戶驗證。該響應必須包含一個適用于被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端可以重復提交一個包含恰當的 Authorization 頭信息的請求。如果當前請求已經包含了 Authorization 證書，那么401響應代表著服務器驗證已經拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那么瀏覽器應當向用戶展示響應中包含的實體信息，因為這個實體信息中可能包含了相關診斷信息。

403:服務器已經理解請求，但是拒絕執行

404:請求失敗，請求所希望得到的資源未被在服務器上發現

500: 服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。

503：由于臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，并且將在一段時間以后恢復。如果能夠預計延遲時間，那么響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 信息，那么客戶端應當以處理500響應的方式處理它。

注意：503狀態碼的存在并不意味著服務器在過載的時候必須使用它。某些服務器只不過是希望拒絕客戶端的連接

?

七層模型

物理層：建立，維護，斷開物理連接

數據鏈路層：建立邏輯連接，進行硬件地址尋址，差錯校驗等功能

網絡層：進行邏輯地址尋址，實現不同網絡之間的路徑選擇

傳輸層：定義傳輸數據的協議端口號，以及流控和差錯校驗

協議有TCP UDP,數據包一旦離開網卡即進入網絡傳輸層

TCP三次協議握手過程：

第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，并進入到SYN_SEND狀態，等待服務器確認

第二次握手：服務器收到syn包，必須確認客戶的SYN(ack=j+1),同時也發送自己的一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1),此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

完成三次握手后，客戶端和服務器開始傳輸數據

會話層：建立，管理，終止會話

表示層：數據的表示，安全，壓縮

應用層：網絡服務與最終用戶的一個借口

協議有：HTTP,FTP,SMTP,DNS,TELNET,HTTPS,DHCP,POP3

?

HTTP協議工作特點

1.???基于B/S模式

2.???通信開銷小，簡單快捷

3.???使用靈活，可使用超文本傳輸協議

4.???節省傳輸時間

5.???無狀態

HTTP工作原理：

客戶端發送請求給服務器，創建一個TCP連接，指定端口號，默認為80，連接到服務器，服務器監聽瀏覽器請求，一旦監聽到客戶端請求，分析請求類型后，服務器會向客戶端返回狀態信息和數據內容。

HTTP協議常見請求/響應頭

HTTP消息頭是在，客戶端請求（Request）或服務器響應（Response）時傳遞的，位請求或響應的第一行，HTTP消息體（請求或響應的內容）是其后傳輸。HTTP消息頭，以明文的字符串格式傳送，是以冒號分隔的鍵/值對，如：Accept-Charset: utf-8，每一個消息頭最后以回車符(CR)和換行符(LF)結尾。HTTP消息頭結束后，會用一個空白的字段來標識，這樣就會出現兩個連續的CR-LF。

HTTP消息頭由IANA（TheInternet Assigned Numbers Authority，互聯網數字分配機構）來整理和維護。其標準最早來源于RFC 4229。IANA將其整理到了消息頭文檔，文檔中還包括了一些新提出的信息頭。

HTTP消息頭支持自定義，自定義的專用消息頭一般會添加'X-'前綴。

?

Content-Type: 請求體的MIME類型（用于POST和PUT請求中）

Content-Type: text/html

Accept:?? 可接受的響應內容類型（Content-Types）。

Accept :text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Origin:? 發起一個針對跨域資源共享的請求（該請求要求服務器在響應中加入一個Access-Control-Allow-Origin的消息頭，表示訪問控制所允許的來源）。

?

Cookie:由之前服務器通過Set-Cookie設置的一個HTTP協議Cookie

?

Cookie: imooc_uuid=bb2a340b-b607-430c-8e71-bdbba95dd952;imooc_isnew_ct=1522329071; loginstate=1; apsid=Y0MzRjMTJhYzVmYTA1MzVmYmI0Yzg0ZDk3OGY1YzYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMzQ4MDEyNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyNDI2NjA5NzUwQHFxLmNvbQAAAAAAAAAAAAAAAAAAADYyNTkxODhlYzk3YTE2NjA0MmI4NGI2Zjc4OTA1ODU2Kea8WinmvFo%3DNm;imooc_isnew=2; PHPSESSID=39ha704aek7ha4ui7vgudjejt4; IMCDNS=0;Hm_lvt_f0cfcccd7b1393990c78efdeebff3968=1522329079,1522329219,1522462327,1524710000;Hm_lpvt_f0cfcccd7b1393990c78efdeebff3968=1524710739; cvde=5ae13a614592b-11

Cache-Control:用來指定當前的請求/回復中的，是否使用緩存機制。

Cache-Control: max-age=0

?

User-Agent:? 瀏覽器的身份標識字符串

User-Agent: Mozilla/5.0 (WindowsNT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3381.1Safari/537.36

?

Referrer: 表示瀏覽器所訪問的前一個頁面，可以認為是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面。Referer其實是Referrer這個單詞，但RFC制作標準時給拼錯了，后來也就將錯就錯使用Referer了

Referer: https://www.imooc.com/

X-Forwarded-FOR:建成XFF頭，它代表客戶端，也就是HTTP的請求端真實的IP，只有在通過了HTTP 代理或者負載均衡服務器時才會添加該項, 在代理轉發及反向代理中經常使用X-Forwarded-For 字段

X-Forwarded-For: client1, proxy1, proxy2。

Access-Control-Allow-Origin:指定哪些網站可以跨域源資源共享

Access-Control-Allow-Origin: *

Last-Modified:所請求的對象的最后修改日期

Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT

?

HTTP協議請求方法

GET,POST,HEAD,OPTIONS,DELETE,PUT,TRACE

HTTP協議的GET和POST請求方法的區別

HTTPS工作原理

HTTPS是一種基于SSL/TLS的HTTP協議，所有的HTTP數據都是在SSL/TLS協議封裝之上傳輸的。

HTTPS協議在HTTP協議的基礎上，添加了SSL/TLS握手和數據加密傳輸，也屬于應用層協議。

?

常見網絡協議含義及端口

FTP:文件傳輸協議 21

Telnet:遠程登錄協議 23

SMTP:簡單郵件傳輸協議 25

POP3：郵局協議第三版 110

HTTP:超文本傳輸協議 80

DNS：域名系統協議 53

總結

以上是生活随笔為你收集整理的计算机网络协议（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。