TCP and UDP related

Preface
difference between TCP and UDP interview in front of the often asked, the Internet also has a lot of content, such as

Difference between TCP and UDP

TCP is connection-oriented, UDP is connectionless
UDP program structure is relatively simple
TCP is a byte-oriented stream, UDP is a datagram-based
TCP guarantees accuracy, UDP packet loss may
TCP guarantees order, UDP does not guarantee
before but also because of the interview to find out about it, but the interviewer asked why TCP is a reliable transport, it revealed the secret, unable to speak, and then two days on a careful understanding of what content in this area, but also a very special subscription Something about time off of the network protocol, therefore, this article focuses on network protocols and interpretations on their own understanding.

  1. UDP
    To understand the difference between TCP and UDP, we must first understand what is TCP, UDP is what

TCP and UDP are transport layer two protocol

We look at the UDP header

Can be seen from FIG, UDP port number in addition to, and consequently substantially no. Without these two port numbers, you do not know which application the data sent.

So UDP is like a child, particularly simple, has the following three features

UDP features

Communication is simple, does not require extensive data structure, processing logic, and header fields
rely on others. It does not establish a connection, but listens to this place, anyone can pass it data, it can also be passed to any personal data, even data can be passed to several people at the same time.
Lengtouqing, things do not understand the work. Not according to the network congestion control, regardless of whether the loss, how to send it or how fat
because UDP is a "child", so the process is not that difficult of a number of projects, and even failure can be received. Based on these characteristics, then, UDP may be used in the following scenarios

UDP's main scenario

Require fewer resources, stable network within the network, or for no loss-sensitive applications, such as DHCP is a UDP-based protocol.
It does not require one to one communication, to build applications connected, but can broadcast. Because it does not face the connection, it can do many, bear broadcast or multicast protocol.
Require fast processing speed, packet loss can be tolerated, but even if the network is congested, also no retreat, indomitable time
based on a few examples of UDP

Live. Live real-time requirements are relatively high, rather packet loss, and do not Caton, so many live applications are based on UDP to achieve their video transmission protocol
real-time game. The game also features real-time high, in this case, the use of reliable UDP protocol custom, custom retransmission strategy, able to generate a minimum of delay, reduce the impact of network problems caused by the game
of things. On the one hand, the Internet of Things interrupt fewer resources, knowledge is likely very small embedded systems, and the maintenance cost of the TCP protocol too; on the other hand, things are particularly high for real-time requirements. For example, Google's Nest resume Thread Group, launched M2M communications protocols Thread, is based on UDP
and some, but can not remember too much written, so keep that in several major enough

  1. TCP
    first is the TCP header format

TCP header has what, what's the use, respectively,

First, the source and destination ports are essential.
Next is the sequence number of the packet. Mainly to solve the disorder problem. Do not know which compiled a good number of how a first-come, after which the
acknowledgment number. The package should be sent out to confirm, so to know if it was received, if not received should be re-sent, this solution is not the problem of loss of
status bits. SYN is initiating a link, ACK is a reply, RST is reconnected, FIN is to end the connection. Because TCP is a connection-oriented, and therefore requires both sides to maintain the status of the connection, these status bits packet will cause the state to change both the
window size, TCP flow control to do, both sides need to communicate with each statement a window, identify their current processing capacity.
By parsing the TCP header, we know to master the TCP protocol, we should focus on the following issues:

Order problem
packet loss problems
connected maintain
flow control
congestion control
three-way handshake 2.1 TCP of
all the problems, first of all have to establish a connection, it is first of all connected to maintenance problems

TCP three-way handshake to establish a connection called, can be simply understood as the following case

A: Hello, I'm A
B: Hello A, I B
A: Hello B

As for why I'm here is the three-way handshake will not go into detail, you can see other people's blog, summary, then that is all there is to have the two sides communicate back

A request is issued for it, and received the response of B, B is responsive to the request A, and also receives the response.

In addition to TCP three-way handshake to establish a connection, mainly to communication problems numbers of TCP packets.

A told B, number of packages from which I initiated the beginning of the number, B also told the A, B number of packages which originated from the beginning of the number.

After establishing a connection requires two sides together to maintain a state machine, in establishing the connection, both the state change of a timing chart is shown below

This is the Internet often see a picture, the beginning of time, the client and server are in CLOSED state, first server active listening on a port, in the LISTEN state. The client then initiates the connection SYN, SYN-SENT state after at. Receives a service initiated connections, return SYN, and ACK (acknowledgment) client SYN, SYN-SENT state after at. After the client receives the SYN and ACK sent by the server, sending the ACK ACK, then it is in ESTAVLISHED state, because it pitch-catch success. After the server receives the ACK ACK, also in ESTABLISHED state, because it pitch-catch up.

2.2 TCP four waved
finish to establish a connection, say a disconnected, also known as the fourth wave, can be simply understood as follows

A: B ah, I do not want to play
B: Oh, you do not want to play, ah, I know
at this time, but A not want to play, that is no longer sends data, but B may also send data is not complete, so the need B is also waiting for active close.
B: A ah, well, I do not play, bye
A: All right, bye

So that the entire connection is closed, of course, the above is just the normal state, some abnormal state (such as A finish does not play, direct running, launched by the end of B of A not answer, do not know how to do or a then B directly on foot do not know how to do), TCP protocol designed several states to deal with these abnormal state

After disconnecting the time when play say A, enters a state FIN_WAIT_1, B receives the message A does not play, into the state of CLOSE_WAIT.

A receives B said knew it, into the state FIN_WAIT_2, if B direct running, then A and at this state forever. TCP protocol, there are no treatment for this condition, but there are Linux, you can adjust tcp_fin_timeout this parameter, set a timeout period.

If you do not run away after B, A to B will not play received a request from the state FIN_WAIT_2 end, A supposedly can run away, but if B does not receive the ACK A foot of it, and I never not receive, so a this time the waiting period, because if B does not receive the ACK, then the a resends to a, the a wait time needs to be long enough.

2.3 Cumulative confirm
how reliable TCP transport?

First, in order to ensure the order of each package has an ID. When establishing a connection will agree on what the initial ID is then sent in one ID, in order to ensure no packet loss, packet needs to be sent must answer, of course, the answer is not one by one, but will answer a previous ID, have received indicate that this model has become a total cumulative response or acknowledgment.

In order to record all packets sent and received packet, TCP sender and the receiver side need to cache these records, respectively, of the buffer in the transmitting side is arranged in accordance with one ID packet, divided into four parts according to the situation of the processing

Send and acknowledgment
sent yet acknowledged
not send waiting to be sent
is not sent and will not send a temporary
part of the third and fourth part here belong to the contents of flow control

In TCP, the receiving end will give the sender window size of a newspaper, called Advertised window. This window shall be equal to add a third portion of the second section above, over the window, the receiver's end, however, can not send the

Thus, the sender to maintain the following data structure

For the receiving end in terms of its content cache inside is simpler

And receiving a confirmed
not received, but can immediately receive
not received, but can not receive the
data corresponding to the following structure

2.4 order and packet loss problems
described above in the figure, at the transmitting end, and acknowledgment sent 1,2,3; 4,5,6,7,8,9 acknowledgment is not sent; 10, 11, 12 is not sent; 13, 14, the receiver is no space, not ready to send.

In the receiving side, the 1,2,3,4,5 ACK is completed but not yet read; is waiting to receive the 6,7; 8,9 is not yet been received an ACK.

The current state of the transmitting end and the receiving end is as follows:

1,2,3 no problem, the two sides agreed
4,5 recipient said ACK, but the sender has not received
6,7,8,9 certainly have made, but has come to 8,9, 6,7 did not to appear out of order, but no way to cache the ACK.
According to this example may know the order of questions and packet loss problems may exist, so let's look to confirm the retransmission mechanism.

4 confirmed the assumption received, ACK 5 are lost, 6 and 7 packets lost, how to do?

One approach is to retry timeout that sent but no ACK packet to set a timer for each of more than a certain event will try again. This time must be greater than the round trip time, but not too long, otherwise the timeout period becomes longer, slower access it.

If over a period of time, 5,6,7 are timed out will be resent. Receiving discovery had received over 5, then dropped 5; 6 received, the ACK transmission, a request is 7,7 unfortunately, lost. 7 again when a timeout, TCP strategy is timeout interval doubled. Whenever there is a retransmission timeout when the next one will speak timeout interval to twice the previous value.

Retransmission timeout mechanism is time-out period can be relatively long, is there a faster way?

There is a fast retransmission mechanism, i.e. when the receiver receives a segment sequence number greater than the desired time, it detects the interval between the data stream, then sends the ACK three redundant, after the client receives, know datagram is lost, then retransmits the lost segment.

For example, the receiver receives the discovery 6,8,9, 7 but did not come, so definitely lost, then sends ACK three 6, 7 is a request. The client receives three, you will find 7 has indeed lost, ranging timeout, immediately re-issued.

2.5 flow control problems
in the flow control mechanism which, in confirmation of the packet, carries a window size

Simply put, what is the receiving end when sending ACK window will bring the size of the buffer, but in general the window reaches a certain size will update the window, because every time updates, just down the air was again filled

2.6 congestion control problem
is controlled by the size of the window, but less than full detection network is quite hard thing, so send TCP packets often been likened to who irrigation management, congestion control, so that is not blocked, no packet loss Bandwidth play as much as possible under the circumstances.

The thickness of the water pipe, the bandwidth network, i.e. how much data can be transmitted per second; pipe having a length, end to end with a time delay. Ideally, the water inside the water pipe thickness * = pipe length. For the network, channel capacity Bandwidth * = round trip delay.

If we set the transmitting window, so that the transmission capacity but unacknowledged packets of the channel can support over the entire pipe.

As shown, assume round-trip time is 8 seconds to 4 seconds, 4 seconds back, transmitting a packet per second, 8 seconds have passed, the eight packages are sent out, the first four of which have reach the receiver, but not to return ACK, the transmission can not be considered successful, the four packets 5-8 in the way, has not been received, this time, just the pipe stays full, the sending end, sent eight unacknowledged packets, exactly equal to the bandwidth, i.e. a packet per transmission, i.e. transmitting a packet per second, round-trip time multiplied by 8 seconds.

If the foundation raised large windows, making the unit more time to send a packet, then the process will be the receiving end, however, the extra packets are dropped, this time, we can add a cache, but the cache inside the package 4 within seconds, certainly less than the receiving end of class, its shortcomings will increase the delay, if the delay reaches a certain level will timeout retransmission

TCP congestion control is mainly to avoid two phenomena, packet loss and retransmission timeout, once there has been too fast these phenomena show sent, and to slow down.

Specific method is the sender slow start, such as pouring water, just started down very slowly, gradually becomes faster. Then setting a threshold value when exceeding this value will slow down

Or slow down in growth, this time it is possible to water overflows, congestion, pour the need to reduce speed, and other water slowly seep down.

Congestion is a manifestation of loss, need retransmission timeout, this time using the fast retransmit algorithm, the current speed is halved. So the speed is still at a relatively high value, nor night returned to liberation.

Summary and interview questions
the difference between TCP and UDP

TCP is connection-oriented, UDP is connectionless
UDP program structure is relatively simple
TCP is a byte-oriented stream, UDP is a datagram-based
TCP guarantees accuracy, UDP packet loss may
TCP guarantees order, UDP does not guarantee
anything is connection-oriented, what is connectionless

Before interoperability, connection-oriented protocol will first establish a connection, such as TCP three-way handshake there, but not UDP

Why is reliable TCP connection

Via a TCP connection error-free data transmission, are not lost, will not be repeated, and arrive in order.
TCP header sequence number which allows data to arrive in order TCP
acknowledgment number of the packet header which does not guarantee packet loss, delayed acknowledgment timeout and retransmission mechanism
TCP has a congestion control mechanism and control flow of
the order of TCP problem, lost packages question, flow control is solved by a sliding window
congestion control is solved by the congestion window

Guess you like

Origin www.cnblogs.com/chong666/p/12370484.html