HTTP1.1 wireshark analysis

The local springboot starts a simple service and then requests a test

tcpdump -i lo0 -nnvv -w tmp.captcpdump local loopback network card

http1.1

Every time HTTP/1.0 communicates, it needs to go through three stages: connection establishment , data transmission and connection disconnection . When a page refers to many external files, the process of establishing and disconnecting will increase a lot of network overhead.

In order to solve the problems of HTTP/1.0, HTTP/1.1 launched in 1999 has the following features:

• Long connection: TCP connection multiplexing is introduced, that is, a TCP is not closed by default and can be multiplexed by multiple requests
• Concurrent connections: Requests for a domain name allow multiple long connections to be allocated (relieves the "head of line blocking" problem in long connections)
• Introduce pipeline mechanism (pipelining), a TCP connection can send multiple requests at the same time. (The order of the response must be consistent with the order of the request, so it is not commonly used)
• Added new methods such as PUT, DELETE, OPTIONS, PATCH, etc.
• Added some cached fields (If-Modified-Since, If-None-Match)
• The range field is introduced in the request header to support resuming uploads from breakpoints
• Allow response data to be chunked (chunked), which is good for transferring large files
• Host header is mandatory to make Internet hosting possible
  ———————————————————
  Copyright statement: This article is the original article of CSDN blogger "Front End Nanjiu", following CC 4.0 BY- SA copyright agreement, please attach the original source link and this statement for reprinting.
  Original link: https://blog.csdn.net/qq_41960279/article/details/123786121

Wireshark analyzes the 2 http requests of http 1.1 keep-alive

As shown below:

When port 8080 is still not good, our browser request can see the following dialogue

The client SYN is going to connect, but the server keeps returning RST.

With RST flag:

RST means reset, which is used to close the connection abnormally. It is indispensable in the design of TCP. As mentioned above, when sending an RST packet to close the connection, you don't have to wait for all the packets in the buffer to be sent out (unlike the FIN packet above), and directly discard the packets in the buffer area and send the RST packet. After receiving the RST packet, the receiving end does not need to send an ACK packet to confirm.

The TCP handler sends RST packets at what it considers to be abnormal moments. For example, A initiates a connection to B, but B does not listen to the corresponding port. At this time, the TCP handler on B's operating system will send a RST packet.

For another example, AB has established a connection normally. During the communication, A sends a FIN packet to B to request to close the connection. After B sends an ACK, the network is disconnected, and A abandons the connection due to several reasons (such as process restart). After the Netcom is connected, B starts to send data packets again. After receiving it, A expresses that he is under a lot of pressure. He does not know where the wild connection comes from, so he sends a RST packet to force the connection to be closed. After B receives it, a connect reset by will appear. peer error.

---

After the SpringBoot project 8080 port is successfully started, you can see that the TCP three-way handshake is successful

---

Then I saw Tcp window update: TCPWindowUpdate is a state in TCP communication. There are many reasons why it can happen, but in the end it is due to the fact that the sender transmits data faster than the receiver reads the data, which makes the receiving end in the buffer. A part of the space must be released to hold the sent data, and then send WindowsUpdate to the sender, telling the sender how fast the data should be sent, so that the data transmission and reception can return to normal.

• Attachment: Wireshark's TCP prompts
  Tcp previous segment lost (tcp previous segment lost)
  Tcpacked lost segment (tcp response lost)
  Tcp window update (tcp window update)
  Tcp dup ack (tcp repeated response)
  Tcp keep alive (tcp keep alive)
  Tcp retransmission (tcp retransmission)
  Tcp ACKed unseen segment (tcp invisible confirmation response)
  tcp port numbers reused (tcp port reuse)
  tcp retransmission (tcp retransmission)
  tcp fast retransmission (tcp fast retransmission)
  TCP Previoussegment lost (sender Data segment loss)
  tcp spurious retransmission (tcp pseudo retransmission)

---

Then the http request is sent

The http server responds to the request and returns

The next http request response (http1.1 Keep-Alive uses TCP connection, no need to disconnect and reconnect)

The client waved 4 times to disconnect

Wireshark analyzes http1.1 keep-alive expired 2 requests

Common keep-alive parameters

• The default KeepAliveTimeout of client IE is 1 minute

• Server IIS default ConnectionTimeout duration is 2min

• Server ASP.NetCore Kestrel default KeepAliveTimeout=130s

• Server nginx default keepalive_timeout=60s

When an http request keep-alive expires, as shown in the figure below, the server will initiate a TCP disconnection and complete 4 handshakes

The next http request re-performs the TCP three-way handshake

keep-alive message

The http request sets the Kepp-Alive time

expiration time to 3 seconds, max is a maximum of 100 requests, and the connection is forcibly disconnected, that is, there is a new connection within the timeout time, and the max will automatically decrease by 1 until it is 0, and the connection is forcibly disconnected. Lose.

• The client sends to the server: TCP detection packet (TCP Keep-Alive)
• The server returns to the client: ACK (TCP Keep-Alive ACK)
  

TCP KeepAliveA detection message is a message without any data, and the ACK flag is set at the same time. The sequence number in the message is the sequence number of the TCP message minus 1 when the data interaction occurred last time. For example, at the last moment of the last data exchange between the local end and the peer end, the sequence number of the ACK message sent by the peer end to the local end is N (that is, the next time the local end sends data to the peer end, the sequence number should be N), then the local end sends data to the peer end. The sequence number of the keep-alive detection packet sent by the peer end should be N-1.