Overview:
- To establish a connection before TCP transfer
- TCP in the Transport layer
- Point-to-point, a TCP can only connect two endpoints
- Reliable transmission, error-free, no loss, no repetition, sequential
- Full Duplex
- BYTE stream
TCP Message Segment
The first 20 bytes of the TCP message segment are fixed, and the latter 4n bytes are added as needed.
20-byte fixed part:
- Source and destination Ports: Write source port number and destination port number, respectively
- Sequence Number : 0-(2^32-1), the first byte ordinal of the data in this section, used to solve the problem of chaos
- confirm the serial number: expected to receive the other side of the next segment of the first data byte ordinal, to solve the packet loss problem
- Data offset: TCP header length, including fixed 20-byte and option fields
- Reserved: all 0
- Control bit: Describes the nature of the message, manipulating the TCP state machine
- window: Refers to the sender's own receive window size, flow control
- Checksum:
- Emergency pointers: Valid when urg=1, indicating the number of bytes of emergency data in this section
- Options:
Establishment and release of the connection three times handshake:
(1) The client makes the Request Connection Message section, Syn=1,seq=x. The client enters the syn-sent state.
(2) When the server receives the request message, it sends a confirmation segment to the client. Confirm that the header of the packet segment is SYN =1,ack = x + 1, and choose an initial serial number seq = Y.server to enter the SYN-RCVD (synchronously received) state.
(3) After the client receives the confirmation message from the server, it also sends a confirmation message to the server. Confirmation Number ack = y + 1, while your own seq = x + 1. This piece of information can already carry data, if not carry the data without consuming serial number, the next segment sequence number is still seq = x + 1.
Why do you have to shake hands three times?
Assuming that the handshake is only two times, if a certain number of times is reported to have been disconnected from the client to the server due to network latency, and when the server assumes that the client wants to establish a new connection, a confirmation message (the second handshake) is sent to the client to establish a new connection. Obviously, it's wrong. If it is a three-time handshake, the client receives this acknowledgment message, ignoring it, the two did not complete the third handshake, so the wrong connection is not established.
Online there is a comparative image of the saying:
First session:
Wife let a go out soy sauce, halfway met a friend B, a asked a sentence: "Dude, have you eaten?"
Results B with headphones to listen to the song, did not hear, did not respond. A heart thought: Talk to you also have no tone, don't tell you, communication failure. The communication must be unsuccessful in the case that B accepts no information transmitted by a.
If b hears what a says, then the first conversation succeeds, and then the second conversation.
Second session:
B heard a said, but he is a foreigner, Chinese is not good, do not know what the meaning of a said and do not know how to answer, so casually answered a sentence learned Chinese: I went to the toilet. A listen to a laugh immediately, "go to the toilet to eat"? The road is different from the conspiracy, away from you, communication failure. Indicates that B failed to communicate correctly in the case of a failure to respond.
If b hears a words, makes the correct answer, and also carries on the rhetorical question: I eat, you? Then the second handshake succeeds.
The first two dialogues proved that B was able to understand the word "a" and could make a correct response. The third conversation follows.
Third session:
A just and B dozen a greeting, suddenly wife shout him, "You a dead, dozen a soy sauce why so half a day, see I go home how to pack you", a wife is strict, listen to frighten apart ran home, put B himself drying that. B thought: This what people ah, have, I also go home, communication failure. Fails to communicate if a statement cannot be answered.
If a has also made the correct answer: I also ate. Then the third dialogue succeeded, the two have established a smooth communication channels, and then began to continue to chat.
The second and third dialogues proved that a can understand what B says and can make the right answer.
It can be seen that two people have effective language communication, the process of three dialogues is necessary.
Source: >
Wave four times
(1) At this point the TCP ends are still in established state, the client no longer sends data, and sends a fin segment, seq = 1, Enter the fin-wait-1 state.
(2) after the server receives the reply, ack = u + 1,seq = V (v equals the number of the last byte of the server transfer data plus 1), then enters the close-wait state, and the server continues to receive the data if it resumes sending it.
(3) after the client receives the confirmation message, it enters the fin-wait-2 state. After the server no longer sends the data, issue fin,ack = u + 1 and enter the Lask-ack state.
(4) after the client receives the reply, Seq = u + 1, ack = w + 1 (w equals the number of the last byte that the server then continues to send, plus 1, which is not necessarily equal to V! ), and then enter the time-wait state
(5) The connection has not been released at this time, need to wait (4 minutes) at both ends will be closed. Setup time waits because it is possible that the last acknowledgment message is missing and needs to be re-transmitted.
Why do you have to wave four times?
Because when the client sends fin, it means that the client has no data to pass, and does not mean that the server has no data to pass to the client, so the server also needs to send fin to indicate that it is not transmitting. Since TCP is full-duplex, there is no question of who first fin.
syn Timeout problem: server will be re-sent if it has not received a confirmation message from the client for a certain amount of time. Under Linux, the default number of retries is 5, and 5 retries are 1, 2, 4, 8, 16, 32s, respectively. If you do not receive it for five times, you will disconnect the connection.
SYN Flood attack problem: If a SYN is sent to the server, the server will have to wait 63 seconds to disconnect, so the attacker can drain the SYN connection queue for the server. Linux has a parameter called Tcp_syncookies to deal with this. When the SYN queue is full, TCP creates a special SEQ number from the source address port, destination address port, and time stamp to send it back (also called a cookie), if the attacker does not have a corresponding, if the connection is normal, then this SYN cookie will be sent back, The server can then establish a connection via a cookie. Do not use tcp_syncookies to handle normal large-load connections. For a normal request, the TCP parameter should be adjusted, the first is: Tcp_synack_retries can use him to reduce the number of retries, the second is: Tcp_max_syn_backlog, you can increase the number of SYN connections; the third is: Tcp_abort_on_ Overflow handle not come over feel direct reject connection!
implementation of TCP reliable transmission
- TCP segment is variable and adjusts to transmit and receive dual caches and network status.
- tcp can time out retransmission
- data check
-
- tcp provides flow control
After sending a message, the sender temporarily saves a copy of the paragraph and deletes it after receiving confirmation.
Confirm that the message section also needs serial number, in order to understand that the data is sent to be confirmed;
The timeout timer is slightly longer than the transport round-trip time, but the exact value is indeterminate, depending on the network condition (using the RTT algorithm).
Continuous ARQ protocol
In order to improve the efficiency, the pipeline transmission is used: The sender can send multiple segments continuously (the length of data sent continuously is called the window). The receiving party does not have to reply to each message received, but adopts the cumulative confirmation method;
flow control and congestion controlDue to the receiver cache limit, the Send window cannot be larger than the accepted Party accept window.
Reference: "TCP those Things (up)" http://coolshell.cn/articles/11564.html
Experimental building TCP/IP network Protocol Foundation HTTPS://WWW.SHIYANLOU.COM/COURSES/98
Computer network Learning Notes-Transport Layer: Introduction to TCP protocol