Android Network programming (1)

This series of articles summarizes the entire Android network programming, including basic TCP/IP protocol, HTTP protocol, HTTPS protocol, httpclient,urlconnection, some network communication libraries to the new cotton Candy added Okhttp.

This paper summarizes the two parts of the connection management and congestion control of TCP protocol.

Connection Management

The TCP protocol is an important protocol for the transport Layer and is responsible for end-to-end communication. In order to achieve reliable connection-oriented transmission, the TCP protocol uses a "three-time handshake" and a "four-wave" way to create a connection and end the connection.

Three-time handshake:

• First handshake: When a connection is established, client C initiates a connection request (Syn=1) to the server S and enters the syn_send state, waiting for the server to return the acknowledgement.
• Second handshake: When the server S receives a connection request from client C, it returns a confirmation message (Syn=1,ack) and enters the SYN_RECV state.
• Third handshake: After the client C receives the acknowledgement message from the server s, it also returns an acknowledgement (Syn=0,ack), enters the established state, and begins transmitting the data.

What you need to mention here is the value of the confirmation number ack= expecting the next byte sequence number.

When you need to disconnect, use the "four-Time Wave" method:

• First wave: After client C sends out the data, it initiates the release of the connection request (Fin=1), which means to turn off data transfer and enter the FIN_WAIT1 state.
• Second wave: When the server receives the request, it continues to send the data (ACK) that was not completed before and enters the close_wait state, closing the read channel, which is no longer able to read the data from the link. C receives an ACK to itself to release the connection request, closes the write channel, no longer writes data to the connection, enters the Fin_wait2 state.
• Third wave: After the server sends the data to be sent, the send closes the Write channel (fin=1) message and enters the Last_ack state. When the client receives the message, it closes the read channel and enters the TIME_WAIT state.
• Fourth wave: Client C sends an ACK to the fin message of the previous server and then enters the closed state after waiting for the time of 2 MSL. The server s also enters the closed state after receiving the ACK.

There are two states to explain the connection setup and release process:

• SYN_RECV: Server S received a connection request from the client, which is called a semi-connected state, and is stored in a semi-connected queue on the server side. When an ACK message from C is received, it is found and removed in the queue. If a flood SYN attack occurs, the half-connection queue overflows and subsequent connection requests are discarded. SYN cookies can be used to prevent flood SYN attacks.
• time_wait: Client C enters the TIME_WAIT state after it sends a confirmation ACK to the fin message of the server S. The client will maintain the status of 2MSL before releasing the socket. This mechanism logically guarantees that the re-allocated socket will not be affected by the delayed re-tweet previously remaining. If client C is turned off directly, if the server s does not receive C for the previous fin message confirmation, the fin message will be re-sent to C, but at this point C is closed, unable to find this connection had to return RST (reset) to S. This has no data loss, but does not meet the requirements of a reliable connection. In addition, if C is closed directly, and then re-established a connection to the server, the port number is the same, but before the previous socket some stranded data will be sent to the server. At this point, the server will think that the stranded data is a new connection sent, creating confusion. Wait for 2MSL to ensure that the data disappears.

Congestion control and flow control

congestion control prevents too much data from being injected into the network, so that routers and links in the network are not overloaded. It is a global process that involves all the hosts and routers on the link. And the flow control is the point-to-point traffic control, is to prevent the sending end of the data sent too fast receiving end too late to receive. The TCP protocol uses slow start, congestion avoidance, fast retransmission, and fast recovery algorithms for congestion control. The sending side maintains a state variable called "congestion window" CWnd, it with the network congestion degree dynamic change, here we first not to consider traffic control and receiver's receiving ability, but let the sender's sending window equals congestion window.

Slow start and congestion avoidance algorithms

When the host starts to send data is not aware of Network load condition, so from small to large gradually increase the sending window, that is, from small to large increase congestion window CWnd. The initial setup CWND=1MSS, sending a message to the receiving party. Upon receipt of the message, the receiving party will return a confirmation. Each time the sender receives a confirmation of the new segment, it increases the CWnd by 1. Therefore, the slow start algorithm is doubled per transmission round RTT, congestion window doubles: 1,2,4 ... So "slow start" is not to say that the CWnd growth rate is slow, but that at the beginning of the transmission of cwnd=1 network test.

To prevent the CWnd from growing too fast, you need to set a slow-start threshold ssthresh State variable:

• When Cwnd<ssthresh, the slow start algorithm is used.
• When Cwnd>ssthresh, the congestion avoidance algorithm is used instead.

Here, the congestion avoidance algorithm differs from the slow-start algorithm, where the congestion window for each transmission-round RTT sender increases by 1, instead of doubling, The value of Ssthresh also increases by 1. Either in the slow-start algorithm or in the congestion avoidance algorithm phase, once congestion occurs (whether or not a confirmation message is received on time), the Ssthresh value is set to 1/2 of the CWnd value when it is congested, and CWnd is set to 1 to restart the slow start algorithm. (This is not the idea of using fast retransmission)

Fast retransmission and fast recovery

During transmission, congestion may occur if the sender has not received a confirmation when the timer expires. For this possible congestion, the fast retransmission algorithm is not used in the above-mentioned scenario. For the fast retransmission algorithm, the receiver is required to send a duplicate acknowledgment each time it receives an out-of-order message, instead of sending an ACK when the data is sent. When the receiving party receives 3 duplicate acknowledgments consecutively, the message should be re-transmitted immediately without waiting for the timer to arrive.

The fast retransmission algorithm needs to be used in conjunction with the fast recovery algorithm. The slow-start threshold ssthresh is halved in order to prevent congestion, while receiving 3 acknowledgment packets and re-sending the message. Instead of executing the slow-start algorithm (cwnd=1), the CWnd is set to a value of Ssthresh halved, and then the congestion avoidance algorithm is executed. In the case of fast recovery algorithms, the slow start algorithm is only used when the TCP connection is established and the network times out.

When we talk about the above four algorithms, let's say that the receiver has a large enough cache to receive the data. However, the receiver cache is limited, so it is necessary to set a receive window Rwnd, which is sent to the sender each time it returns an acknowledgement to the sending party. This receive window is also called the Notification window, and the sending window of the sender from the traffic control angle cannot exceed the receiver's Rwnd value.

Combining congestion control and flow control, the sending window value =min{rwnd,cwnd} is considered.

The HTTP protocol and the HTTPS protocol will be summarized in the next article.

Android Network programming (1)