406 UDP協議是面向非鏈接的協議 Keep-Alive

HTTP The Definitive Guide

 

Table 3-1. Common HTTP methods

 

Method

Description

Message body?

 

GET

Get a document from the server.

No

 

HEAD

Get just the headers for a document from the server.

No

 

POST

Send data to the server for processing.

Yes

 

PUT

Store the body of the request on the server.

Yes

 

TRACE

Trace the message through proxy servers to the server.

No

 

OPTIONS

Determine what methods can operate on a server.

No

 

DELETE

Remove a document from the server.

No

 

Not all servers implement all seven of the methods in Table 3-1. Furthermore, because HTTP was designed to be easily extensible, other servers may implement their own request methods in addition to these. These additional methods are called extension methods, because they extend the HTTP specification.

//這些附加方法是對HTTP規範的擴展

 

 

TCP、UDP和HTTP詳解 - ~風輕雲淡~ - 博客園 https://www.cnblogs.com/gaopeng527/p/5255827.html

http:是用於www瀏覽的一個協議。
tcp：是機器之間創建鏈接用的到的一個協議。

一、TCP/IP是個協議組，可分爲三個層次：網絡層、傳輸層和應用層。
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。
在傳輸層中有TCP協議與UDP協議。
在應用層有FTP、HTTP、TELNET、SMTP、DNS等協議。
所以，HTTP自己就是一個協議，是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。 

二、HTTP協議是創建在請求/響應模型上的。首先由客戶創建一條與服務器的TCP連接，併發送一個請求到服務器，請求中包含請求方法、URI、協議版本以及相關的MIME樣式的消息。服務器響應一個狀態行，包含消息的協議版本、一個成功和失敗碼以及相關的MIME式樣的消息。
HTTP/1.0爲每一次HTTP的請求/響應創建一條新的TCP連接，所以一個包含HTML內容和圖片的頁面將須要創建屢次的短時間的TCP連接。一次TCP連接的創建將須要3次握手。
另外，爲了得到適當的傳輸速度，則須要TCP花費額外的迴路連接時間（RTT）。每一次連接的創建須要這種常常性的開銷，而其並不帶有實際有用的數據，只是保證連接的可靠性，所以HTTP/1.1提出了可持續連接的實現方法。HTTP/1.1將只創建一次TCP的連接而重複地使用它傳輸一系列的請求/響應 消息，所以減小了連接創建的次數和常常性的連接開銷。

三、結論：雖然HTTP自己是一個協議，但其最終仍是基於TCP的。不過，目前，有人正在研究基於TCP+UDP混合的HTTP協議。

具體介紹

IP （網際協議）

在網絡通訊中，網絡組件的尋址對信息的路由選擇和傳輸來講是至關關鍵的。相同網絡中的兩臺機器間的消息傳輸有各自的技術協定。LAN 是經過提供6字節的惟一標識符（「MAC」地址）在機器間發送消息的。SNA 網絡中的每臺機器都有一個邏輯單元及與其相應的網絡地址。DECNET、AppleTalk 和 Novell IPX 均有一個用來分配編號到各個本地網和工做站的配置。

HTTP是超文本傳輸協議，是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議。在Internet上的Web服務器上存放的都是超文本信息， 客戶機須要經過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不只可用於Web訪問，也能夠用於其餘因特網/內聯網應用系統之間的通訊，從而實現各種應用資源超媒體訪問的集成

TCP （傳輸控制協議）

經過序列化應答和必要時重發數據包，TCP 爲應用程序提供了可靠的傳輸流和虛擬鏈接服務。TCP 主要提供數據流轉送，可靠傳輸，有效流控制，全雙工操做和多路傳輸技術。可查閱 TCP 部分獲取更多詳細資料。

至於HTTP協議,它是TCP協議族中的一種。使用TCP80端口

HTTP是應用層協議，TCP是傳輸層協議！

數據包在網絡傳輸過程當中，HTTP被封裝在TCP包內！！

 

1. TCP/UDP

面向鏈接的TCP

「面向鏈接」就是在正式通訊前必需要與對方創建起鏈接。好比你給別人打電話，必須等線路接通了、對方拿起話筒才能相互通話。

 

TCP（Transmission Control Protocol，傳輸控制協議）是基於鏈接的協議，也就是說，在正式收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來，其中的過程很是複雜，咱們這裏只作簡單、形象的介紹，你只要作到可以理解這個過程便可。

 

咱們來看看這三次對話的簡單過程：

1. 主機A向主機B發出鏈接請求數據包：「我想給你發數據，能夠嗎？」，這是第一次對話；

2. 主機B向主機A發送贊成鏈接和要求同步（同步就是兩臺主機一個在發送，一個在接收，協調工做）的數據包：「能夠，你何時發？」，這是第二次對話；

3. 主機A再發出一個數據包確認主機B的要求同步：「我如今就發，你接着吧！」，這是第三次對話。

 

三次「對話」的目的是使數據包的發送和接收同步，通過三次「對話」以後，主機A才向主機B正式發送數據。

TCP協議能爲應用程序提供可靠的通訊鏈接，使一臺計算機發出的字節流無差錯地發往網絡上的其餘計算機，對可靠性要求高的數據通訊系統每每使用TCP協議傳輸數據。

咱們來作一個實驗，用計算機A（安裝Windows 2000 Server操做系統）從「網上鄰居」上的一臺計算機B拷貝大小爲8,644,608字節的文件，經過狀態欄右下角網卡的發送和接收指標就會發現：雖然是 數據流是由計算機B流向計算機A，可是計算機A仍發送了3,456個數據包，如圖2所示。這些數據包是怎樣產生的呢？由於文件傳輸時使用了TCP/IP協 議，更確切地說是使用了面向鏈接的TCP協議，計算機A接收數據包的時候，要向計算機B回發數據包，因此也產生了一些通訊量。

若是事先用網絡監視器監視網絡流量，就會發現由此產生的數據流量是9,478,819字節，比文件大小多出10.96%（如圖3所示），緣由不只在於數據包和幀自己佔用了一些空間，並且也在於TCP協議面向鏈接的特性致使了一些額外的通訊量的產生。

面向非鏈接的UDP協議

「面向非鏈接」就是在正式通訊前沒必要與對方先創建鏈接，無論對方狀態就直接發送。這與如今風行的手機短信很是類似：你在發短信的時候，只須要輸入對方手機號就OK了。

UDP（User Data Protocol，用戶數據報協議）是與TCP相對應的協議。它是面向非鏈接的協議，它不與對方創建鏈接，而是直接就把數據包發送過去！

UDP 適用於一次只傳送少許數據、對可靠性要求不高的應用環境。好比，咱們常用「ping」命令來測試兩臺主機之間TCP/IP通訊是否正常，其實 「ping」命令的原理就是向對方主機發送UDP數據包，而後對方主機確認收到數據包，若是數據包是否到達的消息及時反饋回來，那麼網絡就是通的。例如， 在默認狀態下，一次「ping」操做發送4個數據包。你們能夠看到，發送的數據包數量是4包，收到的也是4包（由於對方主機收到後會發回一 個確認收到的數據包）。這充分說明了UDP協議是面向非鏈接的協議，沒有創建鏈接的過程。正由於UDP協議沒有鏈接的過程，因此它的通訊效果高；但也正由於如此，它的可靠性不如TCP協議高。QQ就使用UDP發消息，所以有時會出現收不到消息的狀況。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　附表：tcp協議和udp協議的差異

	TCP	UDP
是否鏈接	面向鏈接	面向非鏈接
傳輸可靠性	可靠	不可靠
應用場合	傳輸大量的數據，對可靠性要求較高的場合	傳送少許數據、對可靠性要求不高的場景
速度	慢	快

 

TCP協議和UDP協議各有所長、各有所短，適用於不一樣要求的通訊環境

 

 

通訊協議——Http、TCP、UDP - 孤星綴月 - 博客園 http://www.cnblogs.com/xhwy/archive/2012/03/03/2378293.html

 

 都是通訊協議，也就是通訊時所遵照的規則，只有雙方按照這個規則「說話」，對方纔能理解或爲之服務。

TCP   HTTP   UDP三者的關係:

TCP/IP是個協議組，可分爲四個層次：網絡接口層、網絡層、傳輸層和應用層。
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。
在傳輸層中有TCP協議與UDP協議。
在應用層有FTP、HTTP、TELNET、SMTP、DNS等協議。
所以，HTTP自己就是一個協議，是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。
socket: 
這是爲了實現以上的通訊過程而創建成來的通訊管道，其真實的表明是客戶端和服務器端的一個通訊進程，雙方進程經過socket進行通訊，而通訊的規則採用指定的協議。socket只是一種鏈接模式，不是協議,tcp,udp，簡單的說（雖然不許確）是兩個最基本的協議,不少其它協議都是基於這兩個協議如，http就是基於tcp的，.用socket能夠建立tcp鏈接，也能夠建立udp鏈接，這意味着，用socket能夠建立任何協議的鏈接，由於其它協議都是基於此的。

下面咱們主要來看一下和咱們互聯網生活密切相關的協議：HTTP

什麼是Http協議

   HTTP全稱是HyperText Transfer Protocal，即：超文本傳輸協議，從1990年開始就在WWW上普遍應用，是現今在WWW上應用最多的協議，    Http是應用層協議，當你上網瀏覽網頁的時候，瀏覽器和Web服務器之間就會經過HTTP在Internet上進行數據的發送和接收。Http是一個基於請求/響應模式的、無狀態的協議。即咱們一般所說的Request/Response。

URL：

URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源,  基本格式以下

schema://host[:port#]/path/.../[?query-string][#anchor]

scheme               指定低層使用的協議(例如：http, https, ftp)

host                   HTTP服務器的IP地址或者域名

port#                 HTTP服務器的默認端口是80，這種狀況下端口號能夠省略。若是使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/

path                   訪問資源的路徑

query-string       發送給http服務器的數據

anchor-             錨

 

URL 的一個例子

http://www.mywebsite.com/sj/test/test.aspx?name=sviergn&x=true#stuff

Schema:                 http
host:                   www.mywebsite.com
path:                   /sj/test/test.aspx
Query String:           name=sviergn&x=true
Anchor:                 stuff

 

HTTP的Request/Response：

先看Request 消息的結構,   Request 消息分爲3部分

第一部分叫Request line,

 第二部分叫Request header,

第三部分是body. header和body之間有個空行，

 結構以下圖

 

第一行中的Method表示請求方法,好比"POST","GET",  Path-to-resoure表示請求的資源， Http/version-number 表示HTTP協議的版本號

當使用的是"GET" 方法的時候， body是爲空的

好比咱們打開博客園首頁的request 以下

GET http://www.cnblogs.com/ HTTP/1.1
Host: www.cnblogs.com

抽象的東西，難以理解，老感受是虛的， 所謂眼見爲實, 實際見到的東西，咱們才能理解和記憶。 咱們今天用Fiddler，實際的看看Request和Response.

下面咱們打開Fiddler 捕捉一個博客園登陸的Request 而後分析下它的結構, 在Inspectors tab下以Raw的方式能夠看到完整的Request的消息，  

 以下圖

Accept

做用： 瀏覽器端能夠接受的媒體類型,

例如：  Accept: text/html  表明瀏覽器能夠接受服務器回發的類型爲 text/html  也就是咱們常說的html文檔,

若是服務器沒法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)

通配符 * 表明任意類型

例如  Accept: */*  表明瀏覽器能夠處理全部類型,(通常瀏覽器發給服務器都是發這個)

Referer:

做用： 提供了Request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的，好比從我主頁上連接到一個朋友那裏，他的服務器就可以從HTTP Referer中統計出天天有多少用戶點擊我主頁上的連接訪問他的網站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Accept-Language

做用： 瀏覽器申明本身接收的語言。 

語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等；

例如： Accept-Language: en-us

Content-Type

做用：

例如：Content-Type: application/x-www-form-urlencoded

 

Accept-Encoding：

做用： 瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate），（注意：這不是隻字符編碼）;

例如： Accept-Encoding: gzip, deflate

User-Agent

做用：告訴HTTP服務器， 客戶端使用的操做系統和瀏覽器的名稱和版本.

咱們上網登錄論壇的時候，每每會看到一些歡迎信息，其中列出了你的操做系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這每每讓不少人感到很神奇，實際上，服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域容許客戶端將它的操做系統、瀏覽器和其它屬性告訴服務器。

例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

Connection

例如：　Connection: keep-alive   當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接

例如：  Connection: close  表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉， 當客戶端再次發送Request，須要從新創建TCP鏈接。

Content-Length

做用：發送給HTTP服務器數據的長度。

例如： Content-Length: 38

Host（發送請求時，該報頭域是必需的）

做用: 請求報頭域主要用於指定被請求資源的Internet主機和端口號，它一般從HTTP URL中提取出來的

例如: 咱們在瀏覽器中輸入：http://www.guet.edu.cn/index.html

瀏覽器發送的請求消息中，就會包含Host請求報頭域，以下：

Host：http://www.guet.edu.cn

此處使用缺省端口號80，若指定了端口號，則變成：Host：指定端口號

Pragma

做用： 防止頁面被緩存， 在HTTP/1.1版本中，它和Cache-Control:no-cache做用如出一轍

Pargma只有一個用法， 例如： Pragma: no-cache

Cookie:

做用： 最重要的header, 將cookie的值發送給HTTP 服務器

Accept-Charset

做用：瀏覽器申明本身接收的字符集，這就是本文前面介紹的各類字符集和字符編碼，如gb2312，utf-8（一般咱們說Charset包括了相應的字符編碼方案）；

 

 

 

咱們再看Response消息的結構, 和Request消息的結構基本同樣。 一樣也分爲三部分

第一部分叫Response line,

 第二部分叫Response header，

第三部分是body. header和body之間也有個空行, 

 結構以下圖

HTTP/version-number表示HTTP協議的版本號，  status-code 和message 請看下節[狀態代碼]的詳細解釋.

咱們用Fiddler 捕捉一個博客園首頁的Response而後分析下它的結構, 在Inspectors tab下以Raw的方式能夠看到完整的Response的消息，   以下圖

 

Cache-Control

做用: 這個是很是重要的規則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義以下

Cache-Control:Public   能夠被任何緩存所緩存（）

Cache-Control:Private     內容只緩存到私有緩存中

Cache-Control:no-cache  全部內容都不會被緩存

還有其餘的一些用法， 我沒搞懂其中的意思， 請你們參考其餘的資料

Content-Type

做用：WEB服務器告訴瀏覽器本身響應的對象的類型和字符集,

例如:

Content-Type: text/html; charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

Expires

做用: 瀏覽器會在指定過時時間內使用本地緩存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

Last-Modified:

做用： 用於指示資源的最後修改日期和時間。（實例請看上節的If-Modified-Since的實例）

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

Server:

做用：指明HTTP服務器的軟件信息

例如:Server: Microsoft-IIS/7.5

X-AspNet-Version:

做用：若是網站是用ASP.NET開發的，這個header用來表示ASP.NET的版本

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:

做用：表示網站是用什麼技術開發的

例如： X-Powered-By: ASP.NET

Connection

例如：　Connection: keep-alive   當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的鏈接

例如：  Connection: close  表明一個Request完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接會關閉， 當客戶端再次發送Request，須要從新創建TCP鏈接。

Content-Length

指明實體正文的長度，以字節方式存儲的十進制數字來表示。在數據下行的過程當中，Content-Length的方式要預先在服務器中緩存全部數據，而後全部數據再一古腦兒地發給客戶端。

例如: Content-Length: 19847

 Date

做用:  生成消息的具體時間和日期

例如：　Date: Sat, 11 Feb 2012 11:35:14 GMT 

HTTP協議之Get和Post

Http協議定義了不少與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用於描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應着對這個資源的查，改，增，刪4個操做。 咱們最多見的就是GET和POST了。GET通常用於獲取/查詢資源信息，而POST通常用於更新資源信息.

咱們看看GET和POST的區別

1. GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456.  POST方法是把提交的數據放在HTTP包的Body中.

2. GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.

3. GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值，也就是說Get是經過地址欄來傳值，而Post是經過提交表單來傳值。

4. GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.

 

UDP_百度百科 https://baike.baidu.com/item/UDP/571511?fr=aladdin

 

UDP和TCP協議的主要區別是二者在如何實現信息的可靠傳遞方面不一樣。

 

TCP協議中包含了專門的傳遞保證機制，當數據接收方收到發送方傳來的信息時，會自動向發送方發出確認消息；發送方只有在接收到該確認消息以後才繼續傳送其它信息，不然將一直等待直到收到確認信息爲止。與TCP不一樣，UDP協議並不提供數據傳送的保證機制。若是在從發送方到接收方的傳遞過程當中出現數據報的丟失，協議自己並不能作出任何檢測或提示。所以，一般人們把UDP協議稱爲不可靠的傳輸協議。

 

 

應用協議 端口號

DNS 53

TFTP 69

SNMP 161

 

既然UDP是一種不可靠的 網絡協議，那麼還有什麼使用價值或必要呢？其實否則，在有些狀況下UDP協議可能會變得很是有用。由於UDP具備TCP所可望不可即的速度優點。雖然TCP協議中植入了各類安全保障功能，可是在實際執行的過程當中會佔用大量的 系統開銷，無疑使速度受到嚴重的影響。反觀UDP因爲排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大下降了執行時間，使速度獲得了保證。

關於UDP協議的最先規範是 RFC768，1980年發佈。儘管時間已經很長，可是UDP協議仍然繼續在主流應用中發揮着做用。包括視頻 電話會議系統在內的許多應用都證實了UDP協議的存在價值。由於相對於可靠性來講，這些應用更加註重實際性能，因此爲了得到更好的使用效果（例如，更高的畫面幀刷新速率）每每能夠犧牲必定的可靠性（例如，畫面質量）。這就是UDP和TCP兩種協議的權衡之處。根據不一樣的環境和特色，兩種傳輸協議都將在從此的網絡世界中發揮更加劇要的做用。

 

 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Keep-Alive

Keep-Alive 是一個通用消息頭，容許消息發送者暗示鏈接的狀態，還能夠用來設置超時時長和最大請求數。

須要將 The Connection 首部的值設置爲  "keep-alive" 這個首部纔有意義。同時須要注意的是，在HTTP/2 協議中， Connection 和 Keep-Alive  是被忽略的；在其中採用其餘機制來進行鏈接管理。

Header type	General header
Forbidden header name	no

 

parameters

一系列用逗號隔開的參數，每個參數由一個標識符和一個值構成，並使用等號 ( '=') 隔開。下述標識符是可用的：

• timeout：指定了一個空閒鏈接須要保持打開狀態的最小時長（以秒爲單位）。須要注意的是，若是沒有在傳輸層設置 keep-alive TCP message 的話，大於 TCP 層面的超時設置會被忽略。
• max：在鏈接關閉以前，在此鏈接能夠發送的請求的最大值。在非管道鏈接中，除了 0 之外，這個值是被忽略的，由於須要在緊跟着的響應中發送新一次的請求。HTTP 管道鏈接則能夠用它來限制管道的使用。

示例

含有 Keep-Alive 首部的響應示例:

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)