簡(jiǎn)單的說(shuō)呢，http協(xié)議是建立在tco/ip的基礎(chǔ)上的，想要了解http先了解一下tcp

TCPP協(xié)議族里重要的一點(diǎn)就是分層。TCPP協(xié)議族按層次分別分為以下4層:應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。
應(yīng)用層
應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。TCPP協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如,FTP(FileTransfer Protocol,文件傳輸協(xié)議)和DNS( Domain Name System,域名系統(tǒng))服務(wù)就是其中兩類HTP協(xié)議也處于該層。
傳輸層
傳輸層對(duì)上層應(yīng)用層,提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸。在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議:TCP( Transmission ControlProtocol,傳輸控制協(xié)議)和UDP( User Data Protocol,用戶數(shù)據(jù)報(bào)協(xié)議)。

網(wǎng)絡(luò)層(又名網(wǎng)絡(luò)互連層)
網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過(guò)怎樣的路徑(所謂的傳輸路線)到達(dá)對(duì)方計(jì)算機(jī),并把數(shù)據(jù)包傳送給對(duì)方。與對(duì)方計(jì)算機(jī)之間通過(guò)多臺(tái)計(jì)算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時(shí),網(wǎng)絡(luò)層所起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線。
鏈路層(又名數(shù)據(jù)鏈路層,網(wǎng)絡(luò)接口層)
用來(lái)處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū)動(dòng)、NC( Network Interface Card,網(wǎng)絡(luò)適配器,即網(wǎng)卡),及光纖等物理可見(jiàn)部分(還包括連接器等一切傳輸媒介)。硬件上的范疇均在鏈路層的作用范圍之內(nèi)。

與HTTP關(guān)系密切的協(xié)議:IP、TcP和DNS

IP( Internet Protoco)網(wǎng)際協(xié)議

按層次分,IP( Internet Protoco)網(wǎng)際協(xié)議位于網(wǎng)絡(luò)層。 internetProtocol這個(gè)名稱可能聽(tīng)起來(lái)有點(diǎn)夸張,但事實(shí)正是如此,因?yàn)閹缀跛惺褂镁W(wǎng)絡(luò)的系統(tǒng)都會(huì)用到IP協(xié)議。TCPP協(xié)議族中的IP指的就是網(wǎng)際協(xié)議,協(xié)議名稱中占據(jù)了一半位置,其重要性可見(jiàn)一斑。可能有人會(huì)把“IP”和“P地址”搞混,“IP”其實(shí)是一種協(xié)議的名稱。IP協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方。而要保證確實(shí)傳送到對(duì)方那里,則需要滿足各類條件。其中兩個(gè)重要的條件是IP地址和MAC地址( Media Access Control Address)IP地址指明了節(jié)點(diǎn)被分配到的地址,MAC地址是指網(wǎng)卡所屬的固定地址。IP地址可以和MAC地址進(jìn)行配對(duì)。P地址可變換,但MAC地址基本上不會(huì)更改。

TCP協(xié)議

為了準(zhǔn)確無(wú)誤地將數(shù)據(jù)送達(dá)目標(biāo)處,TCP協(xié)議采用了三次握手( three-way handshaking)策略。用TCP協(xié)議把數(shù)據(jù)包送出去后,TCP不會(huì)對(duì)傳送后的情況置之不理,它一定會(huì)向?qū)Ψ酱_認(rèn)是否成功送達(dá)。握手過(guò)程中使用了TCP的標(biāo)志(fag)—SYN( synchronize)和ACKacknowledgement發(fā)送端首先發(fā)送一個(gè)帶SYN標(biāo)志的數(shù)據(jù)包給對(duì)方。接收端收到后,回傳一個(gè)帶有 SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。最后,發(fā)送端再回傳一個(gè)帶ACK標(biāo)志的數(shù)據(jù)包,代表“握手”結(jié)東若在握手過(guò)程中某個(gè)階段莫名中斷,TCP協(xié)議會(huì)再次以相同的順序發(fā)送相同的數(shù)據(jù)包

負(fù)責(zé)域名解析的DNs服務(wù)

DNS( Domain Name System)服務(wù)是和HTP協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到IP地址之間的解析服務(wù)。計(jì)算機(jī)既可以被賦予IP地址,也可以被賦予主機(jī)名和域名。比如www.hackr.jpo用戶通常使用主機(jī)名或域名來(lái)訪問(wèn)對(duì)方的計(jì)算機(jī),而不是直接通過(guò)IP地址訪問(wèn)。因?yàn)榕cIP地址的一組純數(shù)字相比,用字母配合數(shù)字的表示形式來(lái)指定計(jì)算機(jī)名更符合人類的記憶習(xí)慣。但要讓計(jì)算機(jī)去理解名稱,相對(duì)而言就變得困難了。因?yàn)橛?jì)算機(jī)更擅長(zhǎng)處理一長(zhǎng)串?dāng)?shù)字。為了解決上述的問(wèn)題,DNS服務(wù)應(yīng)運(yùn)而生。DNS協(xié)議提供通過(guò)域名查找P地址,或逆向從IP地址反查域名的服務(wù)

進(jìn)入正題

客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下格式：請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)四個(gè)部分組成，下圖給出了請(qǐng)求報(bào)文的一般格式。

客戶端請(qǐng)求：

GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi

服務(wù)端響應(yīng):

HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain

HTTP 請(qǐng)求方法
根據(jù) HTTP 標(biāo)準(zhǔn)，HTTP 請(qǐng)求可以使用多種請(qǐng)求方法。

HTTP1.0 定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了六種請(qǐng)求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序號(hào)方法描述

1	GET	請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。
2	HEAD	類似于 GET 請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭
3	POST	向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST 請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
5	DELETE	請(qǐng)求服務(wù)器刪除指定的頁(yè)面。
6	CONNECT	HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
7	OPTIONS	允許客戶端查看服務(wù)器的性能。
8	TRACE	回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
9	PATCH	是對(duì) PUT 方法的補(bǔ)充，用來(lái)對(duì)已知資源進(jìn)行局部更新 。

HTTP 響應(yīng)頭信息
HTTP請(qǐng)求頭提供了關(guān)于請(qǐng)求，響應(yīng)或者其他的發(fā)送實(shí)體的信息。

在本章節(jié)中我們將具體來(lái)介紹HTTP響應(yīng)頭信息。

應(yīng)答頭說(shuō)明

Allow	服務(wù)器支持哪些請(qǐng)求方法（如GET、POST等）。
Content-Encoding	文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時(shí)間。Java的GZIPOutputStream可以很方便地進(jìn)行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過(guò)查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁(yè)面，為其他瀏覽器返回普通頁(yè)面。
Content-Length	表示內(nèi)容長(zhǎng)度。只有當(dāng)瀏覽器使用持久HTTP連接時(shí)才需要這個(gè)數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢(shì)，可以把輸出文檔寫入 ByteArrayOutputStream，完成后查看其大小，然后把該值放入Content-Length頭，最后通過(guò)byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。
Content-Type	表示后面的文檔屬于什么MIME類型。Servlet默認(rèn)為text/plain，但通常需要顯式地指定為text/html。由于經(jīng)常要設(shè)置Content-Type，因此HttpServletResponse提供了一個(gè)專用的方法setContentType。
Date	當(dāng)前的GMT時(shí)間。你可以用setDateHeader來(lái)設(shè)置這個(gè)頭以避免轉(zhuǎn)換時(shí)間格式的麻煩。
Expires	應(yīng)該在什么時(shí)候認(rèn)為文檔已經(jīng)過(guò)期，從而不再緩存它？
Last-Modified	文檔的最后改動(dòng)時(shí)間。客戶可以通過(guò)If-Modified-Since請(qǐng)求頭提供一個(gè)日期，該請(qǐng)求將被視為一個(gè)條件GET，只有改動(dòng)時(shí)間遲于指定時(shí)間的文檔才會(huì)返回，否則返回一個(gè)304（Not Modified）狀態(tài)。Last-Modified也可用setDateHeader方法來(lái)設(shè)置。
Location	表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過(guò)HttpServletResponse的sendRedirect方法，該方法同時(shí)設(shè)置狀態(tài)代碼為302。
Refresh	表示瀏覽器應(yīng)該在多少時(shí)間之后刷新文檔，以秒計(jì)。除了刷新當(dāng)前文檔之外，你還可以通過(guò)setHeader(“Refresh”, “5; URL=http://host/path”)讓瀏覽器讀取指定的頁(yè)面。注意這種功能通常是通過(guò)設(shè)置HTML頁(yè)面HEAD區(qū)的＜META HTTP-EQUIV=“Refresh” CONTENT=“5;URL=http://host/path"＞實(shí)現(xiàn)，這是因?yàn)?#xff0c;自動(dòng)刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫者十分重要。但是，對(duì)于Servlet來(lái)說(shuō)，直接設(shè)置Refresh頭更加方便。注意Refresh的意義是"N秒之后刷新本頁(yè)面或訪問(wèn)指定頁(yè)面”，而不是"每隔N秒刷新本頁(yè)面或訪問(wèn)指定頁(yè)面"。因此，連續(xù)刷新要求每次都發(fā)送一個(gè)Refresh頭，而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV=“Refresh” …＞。注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個(gè)擴(kuò)展，但Netscape和IE都支持它。
Server	服務(wù)器名字。Servlet一般不設(shè)置這個(gè)值，而是由Web服務(wù)器自己設(shè)置。
Set-Cookie	設(shè)置和頁(yè)面關(guān)聯(lián)的Cookie。Servlet不應(yīng)使用response.setHeader(“Set-Cookie”, …)，而是應(yīng)使用HttpServletResponse提供的專用方法addCookie。參見(jiàn)下文有關(guān)Cookie設(shè)置的討論。
WWW-Authenticate	客戶應(yīng)該在Authorization頭中提供什么類型的授權(quán)信息？在包含401（Unauthorized）狀態(tài)行的應(yīng)答中這個(gè)頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。注意Servlet一般不進(jìn)行這方面的處理，而是讓W(xué)eb服務(wù)器的專門機(jī)制來(lái)控制受密碼保護(hù)頁(yè)面的訪問(wèn)（例如.htaccess）。

HTTP狀態(tài)碼
HTTP狀態(tài)碼分類
HTTP狀態(tài)碼由三個(gè)十進(jìn)制數(shù)字組成，第一個(gè)十進(jìn)制數(shù)字定義了狀態(tài)碼的類型，后兩個(gè)數(shù)字沒(méi)有分類的作用。HTTP狀態(tài)碼共分為5種類型：

分類分類描述

1**	信息，服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作
2**	成功，操作被成功接收并處理
3**	重定向，需要進(jìn)一步的操作以完成請(qǐng)求
4**	客戶端錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求
5**	服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤

狀態(tài)碼狀態(tài)碼英文名稱中文描述

100	Continue	繼續(xù)。客戶端應(yīng)繼續(xù)其請(qǐng)求
101	Switching	Protocols 切換協(xié)議。服務(wù)器根據(jù)客戶端的請(qǐng)求切換協(xié)議。只能切換到更高級(jí)的協(xié)議，例如，切換到HTTP的新版本協(xié)議
200	OK	請(qǐng)求成功。一般用于GET與POST請(qǐng)求
201	Created	已創(chuàng)建。成功請(qǐng)求并創(chuàng)建了新的資源
202	Accepted	已接受。已經(jīng)接受請(qǐng)求，但未處理完成
203	Non-Authoritative Information	非授權(quán)信息。請(qǐng)求成功。但返回的meta信息不在原始的服務(wù)器，而是一個(gè)副本
204	No Content	無(wú)內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。在未更新網(wǎng)頁(yè)的情況下，可確保瀏覽器繼續(xù)顯示當(dāng)前文檔
205	Reset Content	重置內(nèi)容。服務(wù)器處理成功，用戶終端（例如：瀏覽器）應(yīng)重置文檔視圖。可通過(guò)此返回碼清除瀏覽器的表單域
206	Partial Content	部分內(nèi)容。服務(wù)器成功處理了部分GET請(qǐng)求
300	Multiple Choices	多種選擇。請(qǐng)求的資源可包括多個(gè)位置，相應(yīng)可返回一個(gè)資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇
301	Moved Permanently	永久移動(dòng)。請(qǐng)求的資源已被永久的移動(dòng)到新URI，返回信息會(huì)包括新的URI，瀏覽器會(huì)自動(dòng)定向到新URI。今后任何新的請(qǐng)求都應(yīng)使用新的URI代替
302	Found	臨時(shí)移動(dòng)。與301類似。但資源只是臨時(shí)被移動(dòng)。客戶端應(yīng)繼續(xù)使用原有URI
303	See Other	查看其它地址。與301類似。使用GET和POST請(qǐng)求查看
304	Not Modified	未修改。所請(qǐng)求的資源未修改，服務(wù)器返回此狀態(tài)碼時(shí)，不會(huì)返回任何資源。客戶端通常會(huì)緩存訪問(wèn)過(guò)的資源，通過(guò)提供一個(gè)頭信息指出客戶端希望只返回在指定日期之后修改的資源
305	Use Proxy	使用代理。所請(qǐng)求的資源必須通過(guò)代理訪問(wèn)
306	Unused	已經(jīng)被廢棄的HTTP狀態(tài)碼
307	Temporary Redirect	臨時(shí)重定向。與302類似。使用GET請(qǐng)求重定向
400	Bad Request	客戶端請(qǐng)求的語(yǔ)法錯(cuò)誤，服務(wù)器無(wú)法理解
401	Unauthorized	請(qǐng)求要求用戶的身份認(rèn)證
402	Payment Required	保留，將來(lái)使用
403	Forbidden	服務(wù)器理解請(qǐng)求客戶端的請(qǐng)求，但是拒絕執(zhí)行此請(qǐng)求
404	Not Found	服務(wù)器無(wú)法根據(jù)客戶端的請(qǐng)求找到資源（網(wǎng)頁(yè)）。通過(guò)此代碼，網(wǎng)站設(shè)計(jì)人員可設(shè)置"您所請(qǐng)求的資源無(wú)法找到"的個(gè)性頁(yè)面
405	Method Not Allowed	客戶端請(qǐng)求中的方法被禁止
406	Not Acceptable	服務(wù)器無(wú)法根據(jù)客戶端請(qǐng)求的內(nèi)容特性完成請(qǐng)求
407	Proxy Authentication Required	請(qǐng)求要求代理的身份認(rèn)證，與401類似，但請(qǐng)求者應(yīng)當(dāng)使用代理進(jìn)行授權(quán)
408	Request Time-out	服務(wù)器等待客戶端發(fā)送的請(qǐng)求時(shí)間過(guò)長(zhǎng)，超時(shí)
409	Conflict	服務(wù)器完成客戶端的 PUT 請(qǐng)求時(shí)可能返回此代碼，服務(wù)器處理請(qǐng)求時(shí)發(fā)生了沖突
410	Gone	客戶端請(qǐng)求的資源已經(jīng)不存在。410不同于404，如果資源以前有現(xiàn)在被永久刪除了可使用410代碼，網(wǎng)站設(shè)計(jì)人員可通過(guò)301代碼指定資源的新位置
411	Length Required	服務(wù)器無(wú)法處理客戶端發(fā)送的不帶Content-Length的請(qǐng)求信息
412	Precondition Failed	客戶端請(qǐng)求信息的先決條件錯(cuò)誤
413	Request Entity Too Large	由于請(qǐng)求的實(shí)體過(guò)大，服務(wù)器無(wú)法處理，因此拒絕請(qǐng)求。為防止客戶端的連續(xù)請(qǐng)求，服務(wù)器可能會(huì)關(guān)閉連接。如果只是服務(wù)器暫時(shí)無(wú)法處理，則會(huì)包含一個(gè)Retry-After的響應(yīng)信息
414	Request-URI Too Large	請(qǐng)求的URI過(guò)長(zhǎng)（URI通常為網(wǎng)址），服務(wù)器無(wú)法處理
415	Unsupported Media Type	服務(wù)器無(wú)法處理請(qǐng)求附帶的媒體格式
416	Requested range not satisfiable	客戶端請(qǐng)求的范圍無(wú)效
417	Expectation Failed	服務(wù)器無(wú)法滿足Expect的請(qǐng)求頭信息
500	Internal Server Error	服務(wù)器內(nèi)部錯(cuò)誤，無(wú)法完成請(qǐng)求
501	Not Implemented	服務(wù)器不支持請(qǐng)求的功能，無(wú)法完成請(qǐng)求
502	Bad Gateway	作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從遠(yuǎn)程服務(wù)器接收到了一個(gè)無(wú)效的響應(yīng)
503	Service Unavailable	由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無(wú)法處理客戶端的請(qǐng)求。延時(shí)的長(zhǎng)度可包含在服務(wù)器的Retry-After頭信息中
504	Gateway Time-out	充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器，未及時(shí)從遠(yuǎn)端服務(wù)器獲取請(qǐng)求
505	HTTP Version not supported	服務(wù)器不支持請(qǐng)求的HTTP協(xié)議的版本，無(wú)法完成處理

HTTP content-type

常見(jiàn)的媒體格式類型如下：

text/html ： HTML格式
text/plain ：純文本格式
text/xml ： XML格式
image/gif ：gif圖片格式
image/jpeg ：jpg圖片格式
image/png：png圖片格式
以application開(kāi)頭的媒體格式類型：

application/xhtml+xml ：XHTML格式
application/xml： XML數(shù)據(jù)格式
application/atom+xml ：Atom XML聚合格式
application/json： JSON數(shù)據(jù)格式
application/pdf：pdf格式
application/msword ： Word文檔格式
application/octet-stream ： 二進(jìn)制流數(shù)據(jù)（如常見(jiàn)的文件下載）
application/x-www-form-urlencoded ： 中默認(rèn)的encType，form表單數(shù)據(jù)被編碼為key/value格式發(fā)送到服務(wù)器（表單默認(rèn)的提交數(shù)據(jù)的格式）
另外一種常見(jiàn)的媒體格式是上傳文件之時(shí)使用的：

multipart/form-data ： 需要在表單中進(jìn)行文件上傳時(shí)，就需要使用該格式

通信數(shù)據(jù)的轉(zhuǎn)發(fā)程序：代理、網(wǎng)關(guān)、隧道

代理
代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序,它扮演了位于服務(wù)器和客戶端“中間人”的角色,接收由客戶端發(fā)送的請(qǐng)求并轉(zhuǎn)發(fā)給服務(wù)器,同時(shí)也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端
網(wǎng)關(guān)
網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器,接收從客戶端發(fā)送來(lái)的請(qǐng)求時(shí),它就像自己擁有資源的源服務(wù)器一樣對(duì)請(qǐng)求進(jìn)行處理。有時(shí)客戶端可能都不會(huì)察覺(jué),自己的通信目標(biāo)是一個(gè)網(wǎng)關(guān)。
隧道
隧道是在相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn),并保持雙方通信連接的應(yīng)用程序

http的優(yōu)缺點(diǎn)
1通信使用明文可能會(huì)被竊聽(tīng)
2不驗(yàn)證通信方的身份就可能遭遇偽裝
3無(wú)法證明報(bào)文完整性,可能已遭簑改

http+加密+認(rèn)證+完整性保護(hù)=https
1htp加上加密處理和認(rèn)證以及完整性保護(hù)后即是https
2https是身披ssl外殼的http
3相互交換密鑰的公開(kāi)密鑰加密技術(shù)
4證明公開(kāi)密鑰正確性的證書
5https的安全通信機(jī)制

奇奇怪怪的知識(shí)

總結(jié)

以上是生活随笔為你收集整理的http——基础知识的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。