For example: IE access to IIS, get files, it must be to establish a connection, this connection after the completion of the communication, is the client close the connection, or the server close the connection. I used the program to simulate IE and IIS, neither received the disconnected message, that is, there is no trigger OnClose event. I am a connection built with a socket. If there are no active disconnects in both respects, then I suspect that there may be a sign of the end in the transmitted data, what is this sign? Thank you, everyone. Solution?
I don't know how IIS got the HTTP response. There is a field in the package that is usually close
Should be disconnected after the specified length has been received.
HTTP you mean the system design of B/s mode.
There is no such argument of maintaining connectivity at all. After a page is refreshed, the page and server end are disconnected, and the two are not connected.
Always feel you are talking about TCP, programming. If so, both parties can voluntarily disconnect.
To:akirya
The data that is transferred is an HTTP package and should not contain the close field. to:minger909
I am doing the C/s program, using TCP to implement HTTP. You said do not keep the connection, is right, I just want to know, do not keep the connection, which side is disconnected? Is IIS sending the data to close, or IE receiving the data to close it? Puzzled, also did not test out, is not received OnClose event. To: where, when to deal with Cexpcetion?
- the http/1.1 all use TCP as the underlying transport protocol. The HTTP client initiates the establishment of a TCP connection with the server first. Once the connection is established, the browser process and the server process can access TCP through their sockets. As mentioned earlier, the client socket is the "gate" between the client process and the TCP connection, and the server-side socket is the "gate" between the server process and the same TCP connection. The customer sends an HTTP request message to his socket and receives an HTTP response message from its own socket. Similarly, the server receives an HTTP request message from its own socket and sends an HTTP response message to its own socket. Once a client or server sends a message into its own socket, the message is completely under TCP control. TCP provides a reliable data transfer service to HTTP, which means that each HTTP request message sent by the customer will eventually reach the server without compromise, and each HTTP response message sent by the server will eventually reach the customer without damage. We can see a clear advantage of layered network architectures--http don't have to worry about data loss or how TCP recovers details from data loss and sequencing. These are the tasks of the lower protocol layer in TCP and protocol stacks. TCP also uses a congestion control mechanism. This mechanism forces each new TCP connection to start with a relatively slow rate of data transmission, but as long as the network is not congested, each connection can quickly rise to a relatively high rate. The initial phase of this slow transmission is called slow start (slow start). It is important to note that the server does not store any state information about the customer while sending the requested file to the customer. Even if a customer requests the same object again within a few seconds, the server will not respond by saying that it has just sent the object to it. Instead, the server re-sends this object because it has completely forgotten what was done earlier. Since the HTTP server does not maintain the customer's status information, we say that HTTP is a stateless protocol (stateless protocol). HTTP protocol Status code meaning number meaning
-----------------------------------------
"Continue":
"101": Witching Protocols
"$": OK
"201": Created
"202": Accepted
"203": non-authoritative information
"204": No Content
"205": Reset Content
"206": Partial Content
"Multiple": Choices
"301": Moved Permanently
"302": Found
"303": See other
"304": Not Modified
"305": Use Proxy
"307": Temporary Redirect
"$": 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
"$": Internal Server Error
"501": Not implemented
"502": Bad Gateway
"503": Service unavailable
"504": Gateway time-out
"505": HTTP Version not supported
- Non-persistent connections and persistent connections HTTP can use both non-persistent connections (nonpersistent connection) or persistent connections (persistent connection). Http/1.0 uses a non-persistent connection, http/1.1 uses persistent connections by default. Non-persistent connections let's look at the steps for transferring a Web page from the server to the customer in a non-persistent connection. Assume that the shell consists of 1 basic HTML files and 10 JPEG images, and all of these objects reside on the same server host. Then assume that the URL for the basic HTML file is: www.yesky.com/somepath/index.html. Here is the concrete step mule: 1.HTTP The client Initializes a TCP connection to the HTTP server in the server host www.yesky.com. The HTTP server uses the default port number 80 to listen for connection establishment requests from HTTP clients. A 2.HTTP client sends an HTTP request message through a local socket associated with a TCP connection. This message contains the path name/somepath/index.html. The 3.HTTP server receives this request message through the local socket associated with the TCP connection, and then extracts the object/somepath/index.html from the server host's memory or hard disk, sending a response message containing the object through the same socket. The 4.HTTP server tells TCP to close the TCP connection (although TCP will not actually terminate the connection until the client receives the response message). 5.HTTP customers receive this response message via the same socket. The TCP connection is then terminated. The message indicates that the encapsulated object is an HTML file. The client takes out the file and analyzes it to see that there are 10 references to the JPEG object. 6. Repeat step mule 1-4 for each JPEG object that you refer to. The browser displays the Web page to the user while it is receiving it. Different browsers may interpret (that is, display to users) the same Web page in a slightly different way. HTTP has nothing to do with how a customer interprets a Web page, and its specifications ([rfc 1945] and [rfc 2616i) simply define the communication protocol between the HTTP client and the server program. The above step is called using a non-persistent connection because the corresponding TCP connection is closed each time the server issues an object, meaning that each connection does not persist until it can be used to transfer other objects. Each TCP connection is used to transmit only one request message and one response message. For the above example, 11 TCP connections are generated per user request for that web page。 In the above-mentioned step mule, we deliberately do not say whether the customer is through 10 serial TCP connections to obtain all the JPEG objects, or through a parallel TCP connection to obtain some of the JPEG objects. In fact, today's browsers allow users to control the degree of parallel connections through configuration. Most browsers can open 5 to 10 parallel TCP connections by default, and each connection handles a request-response transaction. If you like, you can set the maximum number of concurrent connections to L, so that the 10 connections are built serially. We use parallel connections to shorten response times.
- HTTP Message Format HTTP specification 1.0[rpcl945] and 1.1[RFC 2616] define the format of the HTTP message. The HTTP message is divided into two categories: request message and response at ease. Let's introduce them separately. The HTTP request message below is a typical HTTP request message: get/somedir/page.html h7tp/1.1
Host:www.yesky.com
Connection:close
user-agent:mozilla/4.0
Accept-language:zh-cn
(Additional carriage return and line break)
By examining this simple request message, we can learn a lot from it. First, the message is written in plain ASCII text. Second, there are 5 lines in this message (each line ends with a carriage return and a newline character), and an additional carriage return and line feed after the last line. Of course, a request message can be more than a row, or just one line. The first line of the request message is called the request line, and subsequent lines are referred to as the header row (header). The request line has 3 ning segments: The Method field, the URL field, and the HTTP version of the segment. A method field has several values to choose from, including Get, post, and head. The overwhelming majority of HTTP request messages use the Get method, which is the method that the browser uses to request an object, which is identified in the URL field. This example shows that the browser is/somedir/page.html the request object. The version field is self-explanatory, and in this case the browser implements the http/1.1 version. Now look at each of the header rows in this example. The head row Host:www.yesky.com the host of the requested object. The request message contains the header connection:close is telling the server that the browser does not want to use a persistent connection, and that the server should close the connection when it makes the requested object. Although the browser that produces this request message implements the http/1.1 version, it does not want to use a persistent connection. User-agent the header row specifies the user agent, which is the type of browser that produces the current request. The user agent for this example is mozilla/4.0, which is a version of the Nelscape browser. This header line is useful because the server can actually send different versions of the same object to different types of user agents (these different version bits are addressed with the same URL). Finally, Accept-languag: The head line indicates that if the requested object has a simplified Chinese version, the user prefers to receive this version, and if there is no language version, the server should send its default version. ACCEPT-LANGUAG: Just one of the many content negotiation headers for HTTP. -----------------------
Reference: Understanding WWW service and HTTP protocol
Http://biz.chinabyte.com/209/2151709_2.shtml
Can be either side of the active disconnection.
Just like any other CS program you've made.
Once a party confirms that the message is closed, it can close (). The other party will also receive the Fd_close message. Just take care of your release in close ().
- You can use Netstat to view the current TCP connection when you are testing with the program, and if the close_wait state is present, the socket is "passively closed." If the "time_wait" status appears, the socket is "actively closed." The TCP end process is as follows: Server Client--------------FIN--------------> server:fin_wait_1<--------- ----ACK---------------client:close_wait server:fin_wait_2<-------------fin---------------client after fin is turned off--- -----------ack-------------> server enters the time_wait state after an ACK is issued, it should be IIS actively shutting down the connection. If the client (IE) actively shuts down the connection, the TIME_WAIT state will appear on the client.
The default time for time_wait is twice times the MLS, which is 240 seconds. MLS is the longest surviving time on the web for TCP tablets.
The primary function of the time_wait is to ensure that the closed TCP port is not immediately used. Because when there is a delay in the network, it is possible that when a port is shut down, there are some retransmission TCP slices in the network that are being sent to this port, and if the port immediately establishes a new TCP connection, it may be affected. So use twice times the MSL time to restrict the port from being used immediately.
The problem now is that 4 minutes is a bit long. A lot of time_wait will bring some bad effects, first of all TCP connections each have a data structure, called TCP Control block.time_wait when this data structure is not released. So when there are too many TCP connections, the memory may be occupied a lot.
You can weigh it and decide whether the client or server is actively disconnecting.
I remember this close is the header information in HTTP, and the same as the OK.
HTTP header has a connection keyword, if the close state, that is, the server actively shut down the connection
Khan, the landlord asked the question of HTTP details, how so many people and TCP pulled up. HTTP is a request-response pattern, and sometimes a connection is closed to indicate that the data has been sent, so there is a field in its protocol definition that indicates who closed the connection. http1.0/1.1 supports persistent connections in 1.1, and if the client uses connection:close in the request, the server will gracefully close the connection after sending the response. However, even if the client requires a persistent connection, the server has the right to actively close the connection after the request has been completed, but the response header contains Connection:close. 1.0 and 1.1, but the HTTP1.1 default is persistent, and HTTP1.0 is not.
The result of the search for resources just now is wrong, please point out.
:) HTTP is an application-layer protocol that works on top of TCP. The real connection and disconnection are done by TCP, so when it comes to connection problems, it's natural to have a TCP pull.
Thank you all. The discussion is very thin, I think many friends can use this post to learn about HTTP. HTTP is a Hypertext Transfer protocol built on TCP.
-
HTTP server has been written in two ways: persistent and non-persistent connections
The two methods of connection first depend on whether the HTTP server supports
The standard HTTP server support, the special HTTP server only supports non-persistent connections and non-persistent connections are both server-side/ie can be controlled by the
control mode is connection The : xxxxx field
Connection: close tells the other party to close the socket after this transfer is over
connection: Alive told each other that after this transmission is over, this socket can be used again to simulate persistent connections:
ie request contains connection:alive -> The HTTP server returns a Web page with an HTTP header containing connection: alive -> ie to submit the next request after the number of bytes described in the HTTP header has been received, which continues to include The CONNECTION:&NBSP;ALIVE&NBSP;->&NBSP;HTTP server continues to return the following simulated non-persistent connection:
ie request contains connection:alive -> http Server returns Web page, HTTP header contains connection: close, indicating that it ignores IE's Alive request -> IE closes the socket after the number of bytes described in the HTTP header is received. It is important to note that for persistent connections, the HTTP header returned by the server must contain a content size field to determine the data bytes that IE needs to receive, or the persistent connection will be problematic. Because IE cannot know when it should send the next request. Therefore, when the data field size cannot be determined, the server must actively close socket at the appropriate time (usually the end of data send);
It is recommended not to use MFC, as if portability is not.
- Come to Http://www.debugease.com/vc/2245132.html
is the client or the server actively disconnecting during HTTP communication?
