Happily, in Spring Boot 2 released earlier this year, the default Web container is Netty, which shows that “reactive” containers have become the trend. Both go’s coslave threads and Java’s Reactor thread model are examples of event-based programming with high concurrency. I’ll start this week talking about NiO, what the underlying principles are, what the application architecture is, and how to take advantage of it to build high-performance servers.

Before introducing NIO, it is necessary to understand TCP protocol, because most applications currently operate on the application layer, resulting in a large number of hidden network details, knowing these details and principles is very helpful for our troubleshooting.

1. TCP features

TCP is a connection-oriented protocol that provides reliable full-duplex byte streams to user processes. Ensure reliable and orderly data packets and support flow control. To understand why TCP does this, let’s start with the following aspects:

  1. Why does the IP network layer not ensure the reliability of packets

  2. How does TCP ensure packet reachability and order

  3. How does TCP support traffic control

  4. TCP status and application

2. Why does the IP network layer not ensure the reliability of packets

Let’s start with the OSI network layer. In the following layer, TCP is located at the transport layer, which guarantees the reliability and continuity of the protocol. The specific sending and receiving is determined by the link layer and the physical layer at the bottom, so the work done by TCP is also based on the optimization and improvement of the bottom.

The communication between the client and the server uses application protocol, and the communication at the transport layer uses TCP, which in turn uses a lower layer OF IP protocol, and IP uses some form of data link layer communication.

We know that the data in the network is ultimately transmitted through multiple router connections. The Ethernet protocol at the bottom defines how to compose packets of electronic signals, which solves the point-to-point communication problem of LAN, but cannot solve the interworking problem of multiple Lans.

The IP protocol adopted by the network layer defines a set of its own address rules, mainly addressing and routing functions, according to the IP address of the other party, to find the best path to transmit information. Lans are connected through routers, which are based on IP protocols and direct packets to a routing excuse. However, THE IP protocol does not guarantee the arrival and integrity of packets. In particular, some packets will be discarded in the case of network congestion to ensure data transmission efficiency.

Ensuring integrity, order, and reliability of packets is what TCP protocol is all about.

TCP protocol

1. TCP packet composition

Many networks have a maximum transmission unit (MTU), which is a limit on data frames imposed by the network at the link layer. In the Case of Ethernet, MTU is 1500 bytes. If the length of an IP packet is larger than the MTU value, the packet is fragmented so that the length of each packet is smaller than the MTU value.

The other packet also contains headers, including IP and Ethernet headers in addition to its own Tcp header. IP packets need at least 20 bytes in Ethernet packets, so the maximum IP packet load is 1480 bytes.


What is the size of a TCP packet?

We need the opportunity MSS value to confirm this. MSS is a TCP concept (in the options field at the head). MSS is the maximum segment of TCP packets that can be transmitted at a time. If the length of TCP packet segments is larger than MSS, TCP packets are transmitted in segments. If not set, the default value of MSS is 536 bytes. This means that a TCP packet is about 500 bytes.


2. How to ensure reliability

As mentioned above, the underlying routing and forwarding of packets does not guarantee the reliability and order of packets.

First, to ensure packet integrity, TCP subcontracts packets whose MSS is larger than MSS. The default MSS size is 563 bytes, which is smaller than MUT, to prevent packet fragmentation at the network layer.

Secondly, SEQ and ACK are added, and timeout retransmission mechanism is adopted to ensure packet reliability.


1) the SEQ

To ensure order, TCP assigns a Sequence number (SEQ for short) to each packet. So that the receiving party restores in order. In case of bag loss, you can also know which bag is missing. Generally, the number of the first packet is a random number, which can also start from 1.

2) ACK

So if it’s numbered, how do you make sure it arrives?

Acknowledgement based on ACK. Each time a packet is received, the receiver must return an ACK message to confirm that the packet has been delivered. In addition, the receiver verifies each packet. If errors are found in the verification, no acknowledgement packet is sent, triggering timeout retransmission by the sender.

The ACK contains the following information:

  • Expect to receive the next packet number next SEQ

  • The remaining capacity of the receiver’s receive window


We use Wiershark to capture a packet of OSChina and look at the data of three handshakes.

My local IP address :192.168.1.103 oschinaIp: 116.211.174.177 1.me->osChina:syn=1 seq=x ack=0 2.osChina->me:syn=1 seq=y ack=x+1 3.me->osChina:seq=x+1 ack=y+1Copy the code


Me ->osChina:syn=1 seq=0 ACK =0

OsChina ->me:syn=1 seq=0 ACK =0+1


3, the me – > osChina: seq = 0 + 1 ack = 0 + 1


Compare the three-way handshake.


3) Retransmission timed out

We know that the network is extremely unstable. Even if SEQ and ACK are added to packets to ensure their order, packet loss or timeout is still guaranteed. What if the sender sends data or the receiver replies to ACK messages that are lost or timed out?

RTO: indicates the timeout retransmission time. There is a way to estimate whether a packet has timed out, and RTT is a measure of the round-trip time for a given connection. TCP needs to track these changes and dynamically adjust the timeout RTO.

If the sender does not receive an ACK packet within a certain period of time, it considers that the packet is lost on the network and automatically resends the packet. This mechanism is called timeout retransmission.

During this period, if the receiver does not receive an ACK message due to loss, the sender resends the packet to the receiver. If the sender receives the ACK message of the packet after the timeout timer expires and the sender has repeatedly sent the ACK message, the sender directly discards the ACK message. After receiving the ack message, the receiver will reply again.


Four, flow control

As we know from the above, TCP can ensure the reliability of data, but also take into account the efficiency. The following three aspects should be considered for efficiency:

  1. Batch packet delivery is supported

  2. Congestion control can be supported based on network conditions

  3. It can understand the status of the receiving end to prevent the receiving end from being unable to process it

Based on the above three requirements, the following processing is done.


1. Sliding Windows

If TCP packets need to be sent and confirmed one by one, the efficiency is too low. Sending and confirming one packet at a time ensures reliability, but does not ensure efficiency. You need a way to batch send and confirm, and that’s what sliding Windows does.

Send sliding window:

The sending window moves from left to right. The data before the sending window must be the data that has been sent and confirmed by the receiver. The data that falls within the sending window is the data that can be sent by the sender and the data that cannot be sent after the sending window.


If timeout or loss occurs. So there are two solutions:

2. Select retransmit ARQ, only send lost packets, avoid duplication (high efficiency, prevent to send duplicate)


Another function of the sliding window is to let the sender know the status of the receiver. If the TCP receiver’s cache is full, it can’t handle any more data, and the sender doesn’t know that the sender will tell each other the size of the current sliding window, then the sender will not send any more data.

  1. The receiver also sends acknowledgement immediately after receiving the data, but at the same time announces to the sender that the window size is 0. So the sender will not send the data for the time being.

  2. The packet is not acknowledged immediately upon arrival until the cache has sufficient space. This avoids the sender sliding window. However, there is a problem. The receiver should not delay sending an acknowledgement for longer than the timeout period. If the time is too long, the sender will mistakenly think that the data is lost and resend the data.


2. Congestion control

We know that the network situation has bad friends, in good times, we can send more packets, in bad times, if the rate of sending packets is constant, in addition to increasing the network burden, but also cause too much packet loss, unless more timeout retransmission, which undoubtedly reduces the communication efficiency.

Based on this, TCP communication parties maintain a value called CWND (Congesion Window), which depends on the congestion rate in the network. The value of the sender’s send window is equal to the size of the congesion window. As long as there is no congestion in the network, the value of the congestion window can be increased so that the sender can send more data to the network. Otherwise, the value of the congestion window is reduced to avoid aggravating the congestion rate of the network.

TCP congestion control algorithms are as follows:

  1. Slow start

  2. Congestion avoidance

  3. The fast retransmission

  4. Fast recovery

The specific algorithm implementation method is not introduced, the approximate function is to find a suitable transmission rate based on the current network condition, to prevent excessive burden to the network. For example, slow start means that the packet is sent slowly at the beginning and the rate is adjusted according to packet loss. If the packet is not lost, the packet is sent faster. If the packet is lost, the sending speed is reduced.

5. TCP status

Anyone familiar with TCP knows that when TCP establishes a connection, there are three handshakes and four handshakes when it disconnects. So what are the states?

If the picture above is too confusing to remember, let’s take a look at the next one to sort it out and see how it works.

As you can see from the above, when the connection is successfully ESTABLISHED, the state is ESTABLISHED. When the status of the receiving end is SYN-recV, it indicates that the receiving end replies the second handshake message and waits for the confirmation of the sender. If there are a lot of SYN attacks on the network, there will be a lot of SYN_RECV states. In this case, the problem IP addresses can be located and a large number of fake connections can be solved through firewall filtering.


Missing connections — TIME_WAIT

On the network, if one end of the network is closed voluntarily instead of being closed by a four-way handshake, does the established TCP channel still exist and how long will it be closed? The TCP state is TIME_WAIT. As you can imagine, most closed connections are closed actively rather than through negotiation. Then close, if you can reconnect to the previous TCP channel, or need to create again.

Any TCP implementation must select a value for MSL, which defaults to either 2 minutes or 30 seconds. TIME_WAIT defaults to twice the MSL and lasts between 1 and 4 minutes. MSL is the maximum time that IP packets can live on the network.

TIME_WAIT exists for two reasons: 1) to reliably terminate TCP full-duplex connections and 2) to allow old duplicate sections to disappear from the network

TCP must prevent old duplicate groups of a connection from reappearing after the connection has terminated, thus being misinterpreted as belonging to an incarnation of the same connection, with a time_wait long enough, twice MSL, to allow groups in one direction to survive at most MSL seconds before being discarded.

From TIME_WAIT to CLOSED, there is a timeout set that is 2*MSL (RFC793 defines MSL as 2 minutes and Linux as 30 seconds), after which the current TCP channel is defined as CLOSED.



For more architecture knowledge, please follow my official account, Cool_wier.