比如說：IE訪問IIS，獲取文件，肯定是要建立一個連接，這個連接在完成通訊后，是客戶端Close了連接，還是服務端Close了連接。我用程序測模擬IE和IIS，都沒有收到斷開連接的消息，也就是都沒有觸發OnClose事件。我是用Socket建立的連接。如果兩方面都沒有主動斷開連接，那么我猜測可能是傳輸的數據中有結束的標志，請問這個標志是怎樣的？謝謝各位。
解決方案 »
不知道iis是怎么弄得http的回應包中有個字段通常是close
收到指定長度之后就應該斷開的。
HTTP 你的意思是B/S模式的系統設計吧。
根本不存在保持連接這種說法。一個頁面在刷新完閉之后，頁面和服務器端即斷開連接，兩者不保持連接。
總感覺你是在說TCP、編程。如果是的話，雙方都可以主動斷開連接。
TO: akirya
其中傳輸的數據都是HTTP包，應該不會包含Close字段的。TO：minger909
我在做C/S的程序，用TCP的方式實現HTTP。您說的不保持連接，是對的，我就是想知道，不保持連接，是哪一方斷開的？是IIS發送完數據進行Close的呢，還是IE接收完數據進行Close的呢。不解，也沒有測試出來，就是沒有收到OnClose的事件。To：在什么地方，什么時候來處理CExpcetion呢？
HTTP/1.1都把TCP作為底層的傳輸協議。HTTP客戶端首先發起建立與服務器TCP連接。一旦建立連接，瀏覽器進程和服務器進程就可以通過各自的套接字來訪問TCP。如前所述，客戶端套接字是客戶進程和TCP連接之間的“門”，服務器端套接字是服務器進程和同一TCP連接之間的“門”。客戶往自己的套接字發送HTTP請求消息，也從自己的套接字接收HTTP響應消息。類似地，服務器從自己的套接字接收HTTP請求消息，也往自己的套接字發送HTTP響應消息。客戶或服務器一旦把某個消息送入各自的套接字，這個消息就完全落入TCP的控制之中。TCP給HTTP提供一個可靠的數據傳輸服務;這意味着由客戶發出的每個HTTP請求消息最終將無損地到達服務器，由服務器發出的每個HTTP響應消息最終也將無損地到達客戶。我們可從中看到分層網絡體系結構的一個明顯優勢——HTTP不必擔心數據會丟失，也無需關心TCP如何從數據的丟失和錯序中恢復出來的細節。這些是TCP和協議棧中更低協議層的任務。 TCP還使用一個擁塞控制機制。該機制迫使每個新的TCP連接一開始以相對緩慢的速率傳輸數據，然而只要網絡不擁塞，每個連接可以迅速上升到相對較高的速率。這個慢速傳輸的初始階段稱為緩啟動(slow start)。 需要注意的是，在向客戶發送所請求文件的同時，服務器並沒有存儲關於該客戶的任何狀態信息。即便某個客戶在幾秒鍾內再次請求同一個對象，服務器也不會響應說:自己剛剛給它發送了這個對象。相反，服務器重新發送這個對象，因為它已經徹底忘記早先做過什么。既然HTTP服務器不維護客戶的狀態信息，我們於是說HTTP是一個無狀態的協議(stateless protocol)。HTTP協議狀態碼的含義 號碼 含義
-----------------------------------------
"100" : Continue
"101" : witching Protocols
"200" : OK
"201" : Created
"202" : Accepted
"203" : Non-Authoritative Information
"204" : No Content
"205" : Reset Content
"206" : Partial Content
"300" : Multiple Choices
"301" : Moved Permanently
"302" : Found
"303" : See Other
"304" : Not Modified
"305" : Use Proxy
"307" : Temporary Redirect
"400" : Bad Request
"401" : Unauthorized
"402" : Payment Required
"403" : Forbidden
"404" : Not Found
"405" : Method Not Allowed
"406" : Not Acceptable
"407" : Proxy Authentication Required
"408" : Request Time-out
"409" : Conflict
"410" : Gone
"411" : Length Required
"412" : Precondition Failed
"413" : Request Entity Too Large
"414" : Request-URI Too Large
"415" : Unsupported Media Type
"416" : Requested range not satisfiable
"417" : Expectation Failed
"500" : Internal Server Error
"501" : Not Implemented
"502" : Bad Gateway
"503" : Service Unavailable
"504" : Gateway Time-out
"505" : HTTP Version not supported
非持久連接和持久連接 HTTP既可以使用非持久連接(nonpersistent connection)，也可以使用持久連接(persistent connection)。HTTP/1.0使用非持久連接，HTTP/1.1默認使用持久連接。 非持久連接 讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一台服務器主機中。 再假設該基本HTML文件的URL為:www.yesky.com/somepath/index.html。 下面是具體步騾: 1.HTTP客戶初始化一個與服務器主機www.yesky.com中的HTTP服務器的TCP連接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。 2.HTTP客戶經由與TCP連接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。 3.HTTP服務器經由與TCP連接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。 4.HTTP服務器告知TCP關閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。 5.HTTP客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。 6.給每一個引用到的JPEG對象重復步騾1-4。 瀏覽器在接收web頁面的同時把它顯示給用戶。不同的瀏覽器可能會以略有不同的方式解釋(也就是向用戶顯示)同一個web頁面。HTTP與客戶如何解釋Web頁面沒有任何關系，其規范([RFC 1945]和[RFC 2616I)僅僅定義HTTP客戶程序和服務器程序之間的通信協議。 上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用於傳送其他對象。每個TCP連接只用於傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。 在上述步騾中，我們有意不說清客戶是通過10個串行的TCP連接先后取得所有JPEG對象，還是通過並行的TCP連接同時取得其中某些JPEG對象。實際上，現今的瀏覽器允許用戶通過配置來控制並行連接的程度。大多數瀏覽器默認可以打開5到10個並行的TCP連接，每個連接處理一個請求—響應事務。用戶要是喜歡，可以把最大並行連接數設為l，那樣的話這10個連接是串行地建立的。我們使用並行連接可以縮短響應時間。
HTTP消息格式 HTTP規范1.0[RPcl945]和1.1[RFC 2616]定義了HTTP消息的格式。HTTP消息分為請求消息和響應稍息兩類。下面我們分別進行介紹。 HTTP請求消息 下面是一個典型的HTTP請求消息: GET /somedir/page.html H7TP/1.1
Host:www.yesky.com
Connection:close
User-agent:Mozilla/4.0
Accept-language:zh-cn
(額外的回車符和換行符)
仔細檢查這個簡單的請求消息，我們可從中學到不少東西。首先，這個消息是用普通的ASCII文本書寫的。其次，這個消息共有5行(每行以一個回車符和一個換行符結束)，最后一行后面還有額外的一個回車特和換行符。當然，一個請求消息可以不止這么多行，也可以僅僅只有一行。該請求消息的第一行稱為請求行(request line)，后續各行都稱為頭部行(header)。請求行有3個寧段:方法字段、URL字段、HTTP版本宇段。方法字段有若干個值可供選擇，包括GET、POST和HEAD。HTTP請求消息絕大多數使用GET方法，這是瀏覽器用來請求對象的方法，所請求的對象就在URL字段中標識。本例表明瀏覽器在請求對象/somedir/page.html。版本字段是不言自明的;本例中瀏覽器實現的是HTTP/1.1版本。 現在看一下本例中的各個頭部行。頭部行Host:www.yesky.com定存放所請求對象的主機。請求消息中包含頭部Connection:close是在告知服務器本瀏覽器不想使用持久連接;服務器發出所請求的對象后應關閉連接。盡管產生這個請求消息的瀏覽器實現的是HTTP/1.1版本，它還是不想使用持久連接。User-agent頭部行指定用戶代理，也就是產生當前請求的瀏覽器的類型。本例的用戶代理是Mozilla/4.0，它是Nelscape瀏覽器的一個版本。這個頭部行很有用，因為服務器實際上可以給不同類型的用戶代理發送同一個對象的不同版本(這些不同版本位用同一個URL尋址)。最后，Accept-languag:頭部行指出要是所請求對象有簡體中文版本，那么用戶寧願接收這個版本;如果沒有這個語言版本，那么服務器應該發送其默認版本。Accept-languag:僅僅是HTTP的眾多內容協商頭部之一。-----------------------
參考：了解WWW服務與HTTP協議
http://biz.chinabyte.com/209/2151709_2.shtml
可以是任何一方主動斷開。
就像你編過的CS其他程序一樣。
一旦一方確認信息發送完閉，就可以Close()。另一方同樣會接收到FD_CLOSE消息的。只要在Close()中處理你的釋放工作就可以了。
你可以在用程序測試的時候，用netstat查看一下當前的TCP連接，如果出現close_wait狀態，則說明套接字是“被動關閉的”。如果出現“time_wait"狀態，說明套接字是“主動關閉的”。TCP結束的過程如下:Server Client-------------- FIN --------------> server: fin_wait_1<------------- ACK --------------- client: close_wait server:fin_wait_2<------------- FIN --------------- client發出fin之后就關閉 -------------- ACK -------------> server發出ack后進入time_wait狀態正常情況下，應該是IIS主動關閉連接的。如果客戶端（IE）主動關閉了連接，那么就會在客戶端出現time_wait狀態。
Time_Wait的默認時間是2倍的MLS，就是240秒鍾。MLS是TCP 片在網上的最長存活時間。
TIME_Wait的主要作用是保證關閉的TCP端口不立即被使用。因為當網絡存在延遲時，可能當某個端口被關閉后，網絡中還有一些重傳的TCP片在發向這個端口，如果這個端口立即建立新的TCP連接，則可能會有影響。所以使用2倍的MSL時間來限制這個端口立即被使用。
現在的問題在於，4分鍾的時間有點長。大量的Time_wait會帶來一些不好的影響，首先每個TCP連接都各自有個數據結構，叫TCP Control Block.Time_wait的時候這個數據結構沒有被釋放。所以當有太多的TCP連接時，內存可能會被占用很多。
你可以權衡一下，然后決定是由客戶端還是服務端主動斷開連接。
我記得這個close是在http的頭部信息,和 200 OK是一樣的.
http頭里有個connection的關鍵字的，如果是close狀態，那就是服務器主動關閉了連接
汗，樓主問的問題HTTP的細節問題，怎么這么多人和TCP拉上了。HTTP是請求-響應模式的，而有時候會以關閉連接來表示數據發送完畢，所以在其協議定義中有個字段來表示誰關閉連接。HTTP1.0/1.1都支持持久連接在1.1中，如果客戶端在請求中使用Connection: Close ，服務器端就會在發送完響應后從容關閉連接。但是即使客戶端要求使用持久連接，但是服務器也有權在響應完請求后主動關閉連接，但是要在響應頭在包含Connection: Close 。1.0和1.1一樣，但是HTTP1.1默認是持久連接的，而且HTTP1.0不是。
剛才查資源得的結果，有錯請指出。
HTTP是應用層協議，在TCP之上才能工作。真正建立連接和斷開連接都是由TCP來完成的，所以說到連接問題，自然要和TCP扯上了。
感謝大家。討論的很細，我想很多朋友可以通過該帖子了解一下HTTP。HTTP是建立在TCP上的超文本傳輸協議。
寫過http服務器考慮兩種方式:持久連接和非持久連接
這兩種連接方式首先取決於http服務器是否支持
標准HTTP服務器支持這兩種方式,特殊HTTP服務器只支持非持久連接持久連接和非持久連接都是服務器端/IE端均可控制的
控制方式是用Connection : xxxxx字段
Connection: Close告訴對方這次傳輸結束以后關閉socket
Connection: Alive告訴對方這次傳輸結束以后可以再次利用這個socket以下模擬持久連接:
IE Request 包含Connection:Alive -> HTTP服務器返回網頁,HTTP頭部包含 Connection: Alive -> IE在HTTP頭部描述的字節數接收完畢以后提交下一個請求,其中繼續包含 Connection: Alive -> HTTP服務器繼續返回網頁以下模擬非持久連接:
IE Request 包含Connection:Alive -> HTTP服務器返回網頁,HTTP頭部包含 Connection: Close,表示自己無視IE的Alive請求 -> IE在HTTP頭部描述的字節數接收完畢以后關閉socket需要說明的是,對於持久連接,Server返回的HTTP頭部必須包含一個內容大小字段用來確定IE需要接收的data字節,否則持久連接就會發生問題,因為IE無法獲知自己什么時候應該發送下一個請求.所以無法確定data字段大小的時候,服務器必須在適當的時候(通常是data發送結束)主動關閉socket
建議不要用mfc,好象可移植性不行.
來至 http://www.debugease.com/vc/2245132.html