一、什么是keep-alive模式

我們知道HTTP協議采用“請求-應答”模式，當使用普通模式，即非KeepAlive模式時，每個請求/應答客戶和服務器都要新建一個連接，完成之后立即斷開連接（HTTP協議為無連接的協議）；當使用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接。

? ??http 1.0中默認是關閉的，需要在http頭加入"Connection: Keep-Alive"，才能啟用Keep-Alive；http 1.1中默認啟用Keep-Alive，如果加入"Connection: close "，才關閉。目前大部分瀏覽器都是用http1.1協議，也就是說默認都會發起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep-Alive連接就看服務器設置情況。

二、keep-alive的優點

????????????通過使用keep-alive機制，可以減少tcp連接次數，也意味著可以減少TIME_WAIT狀態連接，以此提高性能和提高http服務器的吞吐率（更少的tcp連接意味著更少的系統內核調用，socket的accept（）和close（）調用）。

? ? ? ? ? RFC還指出單用戶客戶端與任何服務器或代理之間的連接數不應該超過2個。一個代理與其它服務器或代碼之間應該使用超過2 * N的活躍并發連接。這是為了提高HTTP響應時間，避免擁塞（冗余的連接并不能代碼執行性能的提升）。

三、如何判斷消息內容長度的大小

????????Keep-Alive模式，客戶端如何判斷請求所得到的響應數據已經接收完成（或者說如何知道服務器已經發生完了數據）？我們已經知道了，Keep-Alive模式發送完數據HTTP服務器不會自動斷開連接，所以不能再使用返回EOF（-1）來判斷。下面介紹兩種判斷方法：

（1）使用消息首部字段content-length，Conent-Length表示實體內容長度，客戶端（服務器）可以根據這個值來判斷數據是否接收完成。

（2）使用消息首部字段Transfer-Encoding

????????當客戶端向服務器請求一個靜態頁面或者一張圖片時，服務器可以很清楚的知道內容大小，然后通過Content-length消息首部字段告訴客戶端需要接收多少數據。但是如果是動態頁面等時，服務器是不可能預先知道內容大小，這時就可以使用Transfer-Encoding：chunk模式來傳輸數據了。即如果要一邊產生數據，一邊發給客戶端，服務器就需要使用"Transfer-Encoding: chunked"這樣的方式來代替Content-Length。

chunk編碼將數據分成一塊一塊的發生。Chunked編碼將使用若干個Chunk串連而成，由一個標明長度為0的chunk標示結束。每個Chunk分為頭部和正文兩部分，頭部內容指定正文的字符總數（十六進制的數字）和數量單位（一般不寫），正文部分就是指定長度的實際內容，兩部分之間用回車換行(CRLF)隔開。在最后一個長度為0的Chunk中的內容是稱為footer的內容，是一些附加的Header信息（通常可以直接忽略）。

Chunk編碼的格式如下：

Chunked-Body = *chunk?
??????????????????????????????????? "0" CRLF?
??????????????????????????????????? footer?
??????????????????????????????????? CRLF??
chunk?= chunk-size [ chunk-ext ] CRLF?
????????????????? chunk-data CRLF

hex-no-zero = <HEX excluding "0">

chunk-size = hex-no-zero *HEX?
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )?
chunk-ext-name = token?
chunk-ext-val = token | quoted-string?
chunk-data = chunk-size(OCTET)

footer = *entity-header

即Chunk編碼由四部分組成：1、0至多個chunk塊，2、"0" CRLF，3、footer，4、CRLF.而每個chunk塊由：chunk-size、chunk-ext（可選）、CRLF、chunk-data、CRLF組成。

四、關于消息長度

其實，上面2中方法都可以歸納為是如何判斷http消息的大小、消息的數量。RFC 2616對消息的長度總結如下：一個消息的transfer-length（傳輸長度）是指消息中的message-body（消息體）的長度。當應用了transfer-coding（傳輸編碼），每個消息中的message-body（消息體）的長度（transfer-length）由以下幾種情況決定（優先級由高到低）：

（1）任何不含有消息體的消息（如1XXX、204、304等響應消息和任何頭(HEAD，首部)請求的響應消息），總是由一個空行（CLRF）結束。

（2）如果出現了Transfer-Encoding頭字段 并且值為非“identity”，那么transfer-length由“chunked” 傳輸編碼定義，除非消息由于關閉連接而終止。

（3）如果出現了Content-Length頭字段，它的值表示entity-length（實體長度）和transfer-length（傳輸長度）。如果這兩個長度的大小不一樣（i.e.設置了Transfer-Encoding頭字段），那么將不能發送Content-Length頭字段。并且如果同時收到了Transfer-Encoding字段和Content-Length頭字段，那么必須忽略Content-Length字段。

（4）如果消息使用媒體類型“multipart/byteranges”，并且transfer-length 沒有另外指定，那么這種自定界（self-delimiting）媒體類型定義transfer-length 。除非發送者知道接收者能夠解析該類型，否則不能使用該類型。

（5）由服務器關閉連接確定消息長度。（注意：關閉連接不能用于確定請求消息的結束，因為服務器不能再發響應消息給客戶端了。）

為了兼容HTTP/1.0應用程序，HTTP/1.1的請求消息體中必須包含一個合法的Content-Length頭字段，除非知道服務器兼容HTTP/1.1。一個請求包含消息體，并且Content-Length字段沒有給定，如果不能判斷消息的長度，服務器應該用用400 (bad request) 來響應；或者服務器堅持希望收到一個合法的Content-Length字段，用 411 (length required)來響應。

所有HTTP/1.1的接收者應用程序必須接受“chunked” transfer-coding (傳輸編碼)，因此當不能事先知道消息的長度，允許使用這種機制來傳輸消息。消息不應該夠同時包含 Content-Length頭字段和non-identity transfer-coding。如果一個消息同時包含non-identity transfer-coding和Content-Length ，必須忽略Content-Length 。

五、URL

????????URL：統一資源定位符是對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。互聯網上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該怎么處理它。

統一資源定位符是統一資源標志符的一個下種。統一資源標志符確定一個資源，而統一資源定位符不但確定一個資源，而且還表示出它在哪里。在因特網的歷史上，統一資源定位符（URL）的發明是一個非常基礎的步驟。統一資源定位符的語法是一般的，可擴展的，它使用ASCII代碼的一部分來表示互聯網的地址。一般統一資源定位符的開始標志著一個計算機網絡所使用的網絡協議。

結構：基本URL包含模式（或稱協議）、服務器名稱（或IP地址）、路徑和文件名，如“協議://授權/路徑?查詢”。完整的、帶有授權部分的普通統一資源標志符語法看上去如下：協議://用戶名:密碼@子域名.域名.頂級域名:端口號/目錄/文件名.文件后綴?參數=值#標志

第一部分

模式/協議（scheme）：它告訴瀏覽器如何處理將要打開的文件。最常用的模式是超文本傳輸協議（Hypertext Transfer Protocol，縮寫為HTTP），這個協議可以用來訪問網絡。其他協議如下：

http——超文本傳輸協議資源

https——用安全套接字層傳送的超文本傳輸協議

ftp——文件傳輸協議

mailto——電子郵件地址

ldap——輕型目錄訪問協議搜索

file——當地電腦或網上分享的文件

news——Usenet新聞組

gopher——Gopher協議

telnet——Telnet協議

第二部分

文件所在的服務器的名稱或IP地址，后面是到達這個文件的路徑和文件本身的名稱。服務器的名稱或IP地址后面有時還跟一個冒號和一個端口號。它也可以包含接觸服務器必須的用戶名稱和密碼。路徑部分包含等級結構的路徑定義，一般來說不同部分之間以斜線（/）分隔。詢問部分一般用來傳送對服務器上的數據庫進行動態詢問時所需要的參數。

有時候，URL以斜杠“/”結尾，而沒有給出文件名，在這種情況下，URL引用路徑中最后一個目錄中的默認文件（通常對應于主頁），這個文件常常被稱為 index.html 或 default.htm。[1]?

絕對URL

絕對URL（absolute URL）顯示文件的完整路徑，這意味著絕對URL本身所在的位置與被引用的實際文件的位置無關，

相對URL

相對URL（relative URL）以包含URL本身的文件夾的位置為參考點，描述目標文件夾的位置。如果目標文件與當前頁面（也就是包含URL的頁面）在同一個目錄，那么這個文件的相對URL僅僅是文件名和擴展名，如果目標文件在當前目錄的子目錄中，那么它的相對URL是子目錄名，后面是斜杠，然后是目標文件的文件名和擴展名。

如果要引用文件層次結構中更高層目錄中的文件，那么使用兩個句點和一條斜杠。可以組合和重復使用兩個句點和一條斜杠，從而引用當前文件所在的硬盤上的任何文件，

一般來說，對于同一服務器上的文件，應該總是使用相對URL，它們更容易輸入，而且在將頁面從本地系統轉移到服務器上時更方便，只要每個文件的相對位置保持不變，鏈接就仍然是有效地。

大小寫

統一資源定位符一般是分大小寫的，不過服務器管理員可以確定在回復詢問時大小寫是否被區分。有些服務器在收到不同大小寫的詢問時的回復是相同的。地址結尾的"."號在互聯網的發展初期，訪問一個網站不是單純的輸入這樣DNS服務器才能夠識別。后來，微軟公司在WindowsNT3.51中對其進行了修改，可以自動在DNS查詢時自動增加一個.號，隨后UNIX，NetWare也隨之而跟進，讓服務器可以識別結尾沒有"."的域名。但是，符號"."在現在的網址中仍然可以使用，統一資源定位符的日常使用超文本傳輸協議統一資源定位符將從互聯網獲取信息的四個基本元素包括在一個簡單的地址中。

HTTP請求

　　客戶端通過發送HTTP請求向服務器請求對資源的訪問。

　　HTTP請求由三部分組成，分別是： 請求行，消息報頭，請求正文

　　請求行以一個方法符號開頭，后面跟著請求URI和協議的版本，以CRLF作為結尾。

　　請求行以空格分隔。除了作為結尾的CRLF外，不允許出現單獨的CR或LF字符，格式如下：

　　Method Request-URI HTTP-Version CRLF

　　Method表示請求的方法，Request-URI是一個統一資源標識符，標識了要請求的資源，HTTP-Version表示請求的HTTP協議版本，CRLF表示回車換行。

　　例如：

　　GET /test.html HTTP/1.1 (CRLF)

GET方法

　　GET方法用于獲取由Request-URI所標識的資源的信息，常見形式是：

　　GET Request-URI HTTP/1.1

　　當我們通過在瀏覽器的地址欄中直接輸入網址的方式去訪問網頁的時候，瀏覽器采用的就是GET方法向服務器獲取資源。

?

POST方法

　　POST方法用于想服務器發送請求，這點和GET方法沒有區別。但是POST方法要求服務器接收附在請求后面的數據。

　　POST方法在表單提交的時候用的最多。

　　采用POST方法提交表單的例子

　　POST /login.jsp HTTP/1.1 (CRLF)

　　Accept: p_w_picpath/gif (CRLF) (…)

　　Host: www.sample.com (CRLF) (…)

　　…

　　Cache-Control: no-cache (CRLF)

　　(CRLF)

　　username=hello&password=123456

　　當我們在HTML中提交表單時，瀏覽器會根據你的提交方法是get還是post，采用相應的在HTTP協議中的GET或POST方法，向服務器發出請求。

　　注意，在HTML文檔中，書寫get和post，不區分大小寫，但HTTP協議中的GET和POST只能是大寫形式。

?

HEAD方法

　　HEAD方法與GET方法幾乎是一樣的，它們的區別在于HEAD方法只是請求消息報頭，而不是完整的內容。

　　對于HEAD請求的回應部分來說，它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的。

　　利用這個方法，不必傳輸整個資源的內容，就可以得到Request-URI所標識的資源的信息。

　　這個方法通常用于測試超鏈接的有效性，是否可以訪問，以及最近是否更新等。

各瀏覽器與各Web Server對URL均有長度的限制如下：

在http協議中，其實并沒有對url長度作出限制，往往url的最大長度和用戶瀏覽器和Web服務器有關，不一樣的瀏覽器，能接受的最大長度往往是不一樣的，當然，不一樣的Web服務器能夠處理的最大長度的URL的能力也是不一樣的。
下面就是對各種瀏覽器和服務器的最大處理能力做一些說明.

Microsoft Internet Explorer (Browser)
IE瀏覽器對URL的最大限制為2083個字符，如果超過這個數字，提交按鈕沒有任何反應。在我的測試中，這個數字得到驗證。

微軟官方也有說明：

Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.
If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.
However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.

Firefox (Browser)
對于Firefox瀏覽器URL的長度限制為65,536個字符，但當我測試時，最大只能處理8182個字符，這是因為url的長度除了瀏覽器限制外，還會受Web服務器的限制，而我本機使用的是ubuntu apache服務器，最大處理能力為8192個字符(相差10個字符，不知道是什么原因)，一旦超過這個長度，服務器就返回如下錯誤信息。

Safari (Browser)
URL最大長度限制為 80,000個字符。

Opera (Browser)
URL最大長度限制為190,000個字符。

Google (chrome)
url長度一旦超過8182個字符時，出現如下服務器錯誤：

寫道

Request-URI Too Large
The requested URL's length exceeds the capacity limit for this server.
Apache/2.2.12 (Ubuntu) Server at 127.0.1.1 Port 80

Apache (Server)
能接受最大url長度為8,192個字符，但我的測試數據是8,182，10個字符，差別不在，數據具體符合。

Microsoft Internet Information Server(IIS)
能接受最大url的長度為16,384個字符。

通過上面的數據可知，為了讓所有的用戶都能正常瀏覽，我們的URL最好不要超過IE的最大長度限制(2038個字符），當然，如果URL不直接提供給用戶，而是提供給程序調用，側這時的長度就只受Web服務器影響了。

　　

轉載于:https://blog.51cto.com/ab3813/1793439

總結

以上是生活随笔為你收集整理的HTTP服务器中keep-alive 与 url常见问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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