寫在最前面的話：

????最近心里總感覺怪怪的，也不知道為什么。直到今天我才發現我的公眾號上有這么多用戶呢。一個月因為種種原因沒有更文章啦，心里總是過意不去，久等啦各位。以后盡我最大的努力更文章，哈哈哈！整理的這篇文章篇幅比較長，靜下心慢慢看，相信會收獲不少！

心里話

HTTP的兩大特性：

1、無狀態性(stateless)：指的是同一個客戶端訪問服務器兩次，服務器是沒有狀態記錄，不知道這個客戶端是不是曾經訪問過。同時也無法分辨不同的客戶端

2、持久連接：在HTTP1.0的時候使用的是非持久連接，客戶端必須為每個請求建立新的連接對象，每次請求都是兩倍的RTT的開銷。從HTTP1.1開始使用的是持久連接，在一段時間內保持客戶端和服務器之間的連接，允許同一個連接中存在多次的數據請求和響應。

?2.1：持久連接的兩種方式:

? 2.1.1:非流水線方式：客戶端在收到前一個響應后才能發出下一個請求

? 2.1.2：流水線方式：客戶端在收到HTTP的響應報文之前能接著發送新的請求報文

域名解析的原理：

1、一個域中的每個主機名與其IP地址的映射關系由這個域的DNS服務器負責管理，例如："www.it.org”、“ftp.it.org”、“blog.it.org”等主機名都由管理域“it.org”的DNS服務器進行管理，而不能由管理域“org”的DNS服務器進行管理。

2、每個管理域都必須在其直接父域的DNS服務器上注冊該子域的名稱和該子域的DNS服務器地址，例如，必須在管理域“org”的DNS服務器注冊子域“it.org”和其DNS服務器的IP地址后，域名“it.org”才能真正被外界所認可

3、為了方便對頂級域名的統一管理，在頂級域名之上其實還有一個根域名，根域名用點(.)表示，例如，“www.it.org”也可以寫為“www.it.org.”，“www.it.org.”中的最后的那個點(.)就表示根域名。Internet中的根域名由InterNIC(國際互聯網絡信息中心)集中管理，頂級域名和其下的域名則由擁有該域名的組織、公司和個人自己管理。

域名解析的兩種方式

DNS有一個弊端，一個域名看上去只是對應一個單獨的IP地址。還好有幾種方法可以消除這個瓶頸：???????

1>循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說，facebook.com實際上就對應了四個IP地址。????????

2>負載平衡器是以一個特定IP地址進行偵聽并將網絡請求轉發到集群服務器上的硬件設備。一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。????????

3>地理 DNS 根據用戶所處的地理位置，通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的服務器不能夠更新同步狀態，但映射靜態內容的話非常好。????????

4>Anycast 是一個IP地址映射多個物理主機的路由技術。美中不足的是Anycast與TCP協議適應的不是很好，所以很少應用在那些方案中。大多數DNS服務器使用Anycast來獲得高效低延遲的DNS查找。

?瀏覽器與服務器建立TCP連接

16位源端口號：16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是標識報文的返回地址。16位目的端口號：16位的目的端口域定義傳輸的目的。這個端口指明報文接收計算機上的應用程序地址接口。32位序號：32位的序列號由接收端計算機使用，重新分段的報文成最初形式。當SYN出現，序列碼實際上是初始序列碼(Initial Sequence Number，ISN)，而第一個數據字節是ISN+1。這個序列號(序列碼)可用來補償傳輸中的不一致。32位確認序號：32位的序列號由接收端計算機使用，重組分段的報文成最初形式。如果設置了ACK控制位，這個值表示一個準備接收的包的序列碼。4位首部長度：4位包括TCP頭大小，指示何處數據開始。保留(6位)：6位值域，這些位必須是0。為了將來定義新的用途而保留。標志：6位標志域。表示為：緊急標志、有意義的應答標志、推、重置連接標志、同步序列號標志、完成發送數據標志。按照順序排列是：URG、ACK、PSH、RST、SYN、FIN。16位窗口大小：用來表示想收到的每個TCP數據段的大小。TCP的流量控制由連接的每一端通過聲明的窗口大小來提供。窗口大小為字節數，起始于確認序號字段指明的值，這個值是接收端正期望接收的字節。窗口大小是一個16字節字段，因而窗口大小最大為65535字節。16位校驗和：16位TCP頭。源機器基于數據內容計算一個數值，收信息機要與源機器數值 結果完全一樣，從而證明數據的有效性。檢驗和覆蓋了整個的TCP報文段：這是一個強制性的字段，一定是由發送端計算和存儲，并由接收端進行驗證的。16位緊急指針：指向后面是優先數據的字節，在URG標志設置了時才有效。如果URG標志沒有被設置，緊急域作為填充。加快處理標示為緊急的數據段。選項：長度不定，但長度必須為1個字節。如果沒有選項就表示這個1字節的域等于0。數據：該TCP協議包負載的數據。在上述字段中，6位標志域的各個選項功能如下。URG：緊急標志。緊急標志為"1"表明該位有效。ACK：確認標志。表明確認編號欄有效。大多數情況下該標志位是置位的。TCP報頭內的確認編號欄內包含的確認編號(w+1)為下一個預期的序列編號，同時提示遠端系統已經成功接收所有數據。PSH：推標志。該標志置位時，接收端不將該數據進行隊列處理，而是盡可能快地將數據轉由應用處理。在處理Telnet或rlogin等交互模式的連接時，該標志總是置位的。RST：復位標志。用于復位相應的TCP連接。SYN：同步標志。表明同步序列編號欄有效。該標志僅在三次握手建立TCP連接時有效。它提示TCP連接的服務端檢查序列編號，該序列編號為TCP連接初始端(一般是客戶端)的初始序列編號。在這里，可以把TCP序列編號看作是一個范圍從0到4，294，967，295的32位計數器。通過TCP連接交換的數據中每一個字節都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個字節的序列編號。FIN：結束標志。

三次握手

(1)第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。(2)第二次握手：Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，并將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。(3)第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client與Server之間可以開始傳輸數據了。簡單來說，就是1、建立連接時，客戶端發送SYN包(SYN=i)到服務器，并進入到SYN-SEND狀態，等待服務器確認2、服務器收到SYN包，必須確認客戶的SYN(ack=i+1),同時自己也發送一個SYN包(SYN=k),即SYN+ACK包，此時服務器進入SYN-RECV狀態3、客戶端收到服務器的SYN+ACK包，向服務器發送確認報ACK(ack=k+1),此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手，客戶端與服務器開始傳送數據。SYN攻擊：在三次握手過程中，Server發送SYN-ACK之后，收到Client的ACK之前的TCP連接稱為半連接(half-open connect)，此時Server處于SYN_RCVD狀態，當收到ACK后，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，并向Server不斷地發送SYN包，Server回復確認包，并等待Client的確認，由于源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：#netstat -nap | grep SYN_RECV

?瀏覽器給web服務器發送一個http請求：

請求行：由請求方法、URL和HTTP協議版本3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。而常見的有如下幾種：

? ??????1>GET：當客戶端要從服務器中讀取文檔時，當點擊網頁上的鏈接或者通過在瀏覽器的地址欄輸入網址來瀏覽網頁的，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數據部分，回送給客戶端。使用GET方法時，請求參數和對應的值附加在URL后面，利用一個問號(“?”)代表URL的結尾與請求參數的開始，傳遞參數長度受限制。例如，/index.jsp?id=100&op=bind。通過GET方式傳遞的數據直接放在在地址中，所以GET方式的請求一般不包含”請求內容”部分，請求數據以地址的形式表現在請求行。地址中”?”之后的部分就是通過GET發送的請求數據，我們可以在地址欄中清楚的看到，各個數據之間用”&”符號隔開。顯然這種方式不適合傳送私密數據。另外，由于不同的瀏覽器對地址的字符限制也有所不同，一般最多只能識別1024個字符，所以如果需要傳送大量數據的時候，也不適合使用GET方式。如果數據是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII。

? ? 2>POST：允許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，可以傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，而且也不會顯示在URL中。POST方式請求行中不包含數據字符串，這些數據保存在“請求內容”部分，各數據之間也是使用”&“符號隔開。POST方式大多用于頁面的表單中。因為POST也能完成GET的功能，因此多數人在設計表單的時候一律都使用POST方式，其實這是一個誤區。GET方式也有自己的特點和優勢，我們應該根據不同的情況來選擇是使用GET還是使用POST。????????

??????? 3>HEAD：就像GET，只不過服務端接受到HEAD請求后只返回響應頭，而不會發送響應內容。當我們只需要查看某個頁面的狀態的時候，使用HEAD是非常高效的，因為在傳輸的過程中省去了頁面內容。?

請求頭部：由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號”:“分隔。請求頭部通知服務器有關于客戶端請求的信息，典型的請求頭有：?????

User-Agent：產生請求的瀏覽器類型。?????

Accept：客戶端可識別的內容類型列表。星號 “ * ” 用于按范圍將類型分組，用 “ */* ” 指示可接受全部類型，用“ type/* ”指示可接受 type 類型的所有子類型。?????

Host：要請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。?????

Accept-Language：客戶端可接受的自然語言。?????

Accept-Encoding：客戶端可接受的編碼壓縮格式。?????

Accept-Charset：可接受的應答的字符集。?????

connection：連接方式(close 或 keepalive)。?????

Cookie：存儲于客戶端擴展字段，向同一域名的服務端發送屬于該域的cookie。

空行：最后一個請求頭部之后是一個空行，發送回車符和換行符，通知服務器以下不再有請求頭部。

請求數據：請求數據不在GET方法中使用，而在POST方法中使用。POST方法適用于需要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭部是Content-Type和Content-Length。

請求報文實例POST /search HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,application/msword, application/x-silverlight, application/x-shockwave-flash, */* Referer: http://www.google.cn/ Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld) Host: www.google.cn Connection: Keep-Alive Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-FxlRugatx63JLv7CWMD6UB_O_r hl=zh-CN&source=hp&q=domety

服務器的永久重定向響應

????服務器給瀏覽器響應一個301永久重定向響應，這樣瀏覽器就會訪問“http://www.facebook.com/” 而非“http://facebook.com/”。為什么服務器一定要重定向而不是直接發送用戶想看的網頁內容呢？其中一個原因跟搜索引擎排名有關。如果一個頁面有兩個地址，就像http://www.igoro.com/和http://igoro.com/，搜索引擎會認為它們是兩個網站，結果造成每個搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是什么意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成緩存友好性變差，當一個頁面有好幾個名字時，它可能會在緩存里出現好幾次。

狀態行：由HTTP協議版本、服務器返回的響應狀態碼和響應狀態碼的文本描述組成。(開發者手冊：https://cloud.tencent.com/developer/section/1190118)狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。?????????????

1xx：信息性狀態碼，表示服務器已接收了客戶端請求，客戶端可繼續發送請求。????????? ?100?Continue?????????????????

? 101?Switching Protocols?????????????

2xx：成功狀態碼，表示服務器已成功接收到請求并進行處理。?????????????????

200?OK 表示客戶端請求成功(一個成功的結果PUT還是DELETE往往不是一個200 OK而是一個204 No Content(或201 Created當資源被上傳的第一次))?????????????????

204?No Content 成功，但不返回任何實體的主體部分?????????????????

206?Partial Content 成功執行了一個范圍(Range)請求?????????????

3xx：重定向狀態碼，表示服務器要求客戶端重定向。?????????????????

301?Moved Permanently 永久性重定向，響應報文的Location首部應該有該資源的新URL? ? ??? ? ? ??

302?Found 臨時性重定向，響應報文的Location首部給出的URL用來臨時定位資源?????????????????

303?See Other 請求的資源存在著另一個URI，客戶端應使用GET方法定向獲取請求的資源? ? ?

304?Not Modified 客戶端發送附帶條件的請求(請求首部中包含如If-Modified-Since等指定首部)時，服務端有可能返回304，此時，響應報文中不包含任何報文主?體。? ? ? ? ? ? ? ? ? ? ? ? ?307?Temporary Redirect 臨時重定向。與302 Found含義一樣。302禁止POST變換為GET，但實際使用時并不一定，307則更多瀏覽器可能會遵循這一標準，但也依賴于瀏覽器具體實現???????????? 4xx：客戶端錯誤狀態碼，表示客戶端的請求有非法內容。?????????????????

400?Bad Request 表示客戶端請求有語法錯誤，不能被服務器所理解????????????????

?401?Unauthonzed 表示請求未經授權，該狀態代碼必須與 WWW-Authenticate 報頭域一起使用?????????????????

403?Forbidden 表示服務器收到請求，但是拒絕提供服務，通常會在響應正文中給出不提供服務的原因????????????????

?404?Not Found 請求的資源不存在，例如，輸入了錯誤的URL?????????????

5xx：服務器錯誤狀態碼，表示服務器未能正常處理客戶端的請求而出現意外錯誤。? ? ? ? ? ?? ? ??500?Internel Server Error 表示服務器發生不可預期的錯誤，導致無法完成客戶端的請求? ? ? ? ? ? ??? ?503?Service Unavailable 表示服務器當前不能夠處理客戶端的請求，在一段時間之后，服務器可能會恢復正常

響應頭部：由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號”:“分隔，典型的響應頭有：??????????

Location：用于重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，服務器端可以發回Location響應報頭后使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源??????????

Server：包含了服務器用來處理請求的軟件信息及其版本。它和 User-Agent 請求報頭域是相對應的，前者發送服務器端軟件的信息，后者發送客戶端軟件(瀏覽器)和操作系統的信息??????????

Vary：指示不可緩存的請求頭列表??????????

Connection：連接方式?對于請求來說：close(告訴 WEB 服務器或者代理服務器，在完成本次請求的響應后，斷開連接，不等待本次連接的后續請求了)。keepalive(告訴WEB服務器或者代理服務器，在完成本次請求的響應后，保持連接，等待本次連接的后續請求);對于響應來說：close(連接已經關閉); keepalive(連接保持著，在等待本次連接的后續請求);

Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望WEB 服務器保持連接多長時間(秒);例如：Keep-Alive：300;　　???

WWW-Authenticate：必須被包含在401 (未授權的)響應消息中，這個報頭域和前面講到的Authorization 請求報頭域是相關的，當客戶端收到 401 響應消息，就要決定是否請求服務器對其進行驗證。如果要求服務器對其進行驗證，就可以發送一個包含了Authorization 報頭域的請求

空行：最后一個響應頭部之后是一個空行，發送回車符和換行符，通知瀏覽器以下不再有響應頭部。

響應數據：服務器返回給客戶端的文本信息。?

響應報文示例HTTP/1.1 301 Moved PermanentlyCache-Control: private, no-store, no-cache, must-revalidate, post-check=0,pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTLocation: "http://www.facebook.com/">P3P: CP=”DSP LAW”Pragma: no-cacheSet-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;path=/; domain=.facebook.com; httponlyContent-Type: text/html; charset=utf-8X-Cnection: closeDate: Fri, 12 Feb 2010 05:09:51 GMTContent-Length: 0

瀏覽器跟蹤重定向地址

? ? ? ? ??現在瀏覽器知道了 “HTTP://www.facebook.com/”才是要訪問的正確地址，所以它會發送另一個http請求。

服務器處理請求

? ? ??? ? ? 服務器接收到獲取請求，然后處理并返回一個響應。這表面上看起來是一個順向的任務，但其實這中間發生了很多有意思的東西，就像作者博客這樣簡單的網站，何況像facebook那樣訪問量大的網站呢！web服務器軟件(像IIS和阿帕奇)接收到HTTP請求，然后確定執行某一請求處理來處理它。請求處理就是一個能夠讀懂請求并且能生成HTML來進行響應的程序(像ASP.NET,PHP,RUBY…)。?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 待續！！！！！

服務器發回一個HTML響應? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? 待續！！！！！

釋放TCP連接????? 若connection 模式為close，則服務器主動關閉TCP 連接，客戶端被動關閉連接，釋放TCP 連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;

四次揮手

(1)第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。(2)第二次揮手：Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1(與SYN相同，一個FIN占用一個序號)，Server進入CLOSE_WAIT狀態。(3)第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。(4)第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。為什么建立連接是三次握手，而關閉連接卻是四次揮手呢？這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送。為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？原因有二：一、保證TCP協議的全雙工連接能夠可靠關閉二、保證這次連接的重復數據段從網絡中消失先說第一點，如果Client直接CLOSED了，那么由于IP協議的不可靠性或者是其它網絡原因，導致Server沒有收到Client最后回復的ACK。那么Server就會在超時之后繼續發送FIN，此時由于Client已經CLOSED了，就找不到與重發的FIN對應的連接，最后Server就會收到RST而不是ACK，Server就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數據丟失，但是卻導致TCP協議不符合可靠連接的要求。所以，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最后正確的關閉連接。再說第二點，如果Client直接CLOSED，然后又再向Server發起一個新連接，我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什么問題，但是還是有特殊情況出現：假設新連接和已經關閉的老連接端口號是一樣的，如果前一次連接的某些數據仍然滯留在網絡中，這些延遲數據在建立新連接之后才到達Server，由于新連接和老連接的端口號是一樣的，又因為TCP協議判斷不同連接的依據是socket pair，于是，TCP協議就認為那個延遲的數據是屬于新連接的，這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連接的所有數據都從網絡中消失。? ? ? ?

客戶端瀏覽器解析HTML內容?????? 客戶端將服務器響應的 html 文本解析并顯示? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ?待續！！? ? ?

瀏覽器獲取嵌入在HTML中的對象

?????? 在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時瀏覽器會發送一個獲取請求來重新獲得這些文件。這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等…

? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ?待續！！！

- END -

長風破浪會有時，直掛云帆濟滄海！

總結

以上是生活随笔為你收集整理的get请求报500_http请求和响应的全过程的全部內容，希望文章能夠幫你解決所遇到的問題。

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