Overview of TCP/UDP knowledge

How does TCP ensure reliable transmission? Validation mechanism: ensure that each data packet can be received, error check: ensure that the data packet is correct, traffic control: ensure that the receiver will not overflow. Sequence Number: ensure the transmission order 1. Five features of the reliable transmission service of TCP/IP: oriented to data stream, virtual circuit connection, buffer transmission, unstructured data stream, full duplex connection. Www.2cto.com 2. TCP adopts the validation technology with retransmission function as the basis for reliable data stream transmission service. 3. In order to improve the efficiency of the data stream transmission process, the sliding window protocol is introduced based on the above, which allows the sender to send multiple groups before waiting for a confirmation. The sliding window protocol requires that only unconfirmed groups need to be re-transmitted, and the maximum number of unconfirmed groups is the size of the window. 4. TCP function: TCP defines the formats of data and validation information exchanged for reliable transmission between two computers, and measures taken by the computer to ensure correct data arrival. 5. a TCP connection is a virtual circuit connection, which is identified by a pair of endpoints. The endpoints are defined as a pair of Integers (host, port). The host is the IP address of the host, port is the TCP port number on the host. 6. TCP uses a dedicated Sliding Window Protocol mechanism to solve the transmission efficiency and traffic control issues. TCP uses the sliding window mechanism to solve the end-to-end traffic control, but does not solve the whole network congestion control. 7. TCP allows a small window to be changed at any time. The advertised value indicates how much data the receiver can receive. The advertised value increases, and the sender expands the sliding window. The advertised value decreases, the sender can narrow down the sending window. 8. TCP packets are divided into two parts: header and data. The header carries the required identification and control information. The confirmation number field indicates the sequence number of the next byte group to be received by the local machine. The value of the sequence number field is the position of the upstream data stream of the message segment, that is, the sending sequence number; the confirmation number refers to the data flow in the opposite direction as the message segment flows. Www.2cto.com 9. TCP uses 6-bit long code bits to indicate the Application Purpose and content of the packet segment. URG emergency pointer fields are available; ACK confirmation fields are available; PSH request for urgent and near operations; RST Connection Reset; SYN synchronization sequence number; FIN sender's byte stream ends. 10. TCP's three-way handshake to establish a TCP connection, the two systems need to synchronize their initial TCP serial number ISN. The serial number is used to track the communication order and ensure that multiple packets are not lost during transmission. The initial serial number is the starting serial number when a TCP connection is established. Synchronization is achieved by exchanging data packets with ISN and 1-bit SYN control bits. A handshake can be initiated by one or both parties.
Difference Between TCP and UDP: 1. based on connection and no connection 2. requirements on system resources (more TCP and less UDP) 3. stream mode and datagram Mode 4. TCP ensures data correctness, UDP may cause packet loss, and TCP ensures data order
Connection-free: Connection and less onless are common terms in network transmission. Their relationships can be illustrated in an image, that is, making calls and writing letters. When making a call, a person must first dial (send a connection request), wait for the response from the other party, and then answer the call (establish a connection) before passing information to each other. After the call is complete, you need to stop the call (disconnect) to complete the call process. Writing a letter is different. You only need to fill in the recipient's address information, and then put the letter into the post office, even if the task is completed. At this time, the Post Office will deliver the mail to the specified destination based on the recipient's address information. We can see that the two are very different. During a call, both parties must establish a connection to transmit information. Connections also ensure the reliability of information transmission. Therefore, connection-oriented protocols must be reliable. Without a connection, there is not much attention. No matter whether the other party has a response or feedback, it simply sends the information. Just as once a letter enters the mailbox, you cannot track its whereabouts until it reaches the destination. Even if the recipient receives the letter, it will not notify you when it will arrive. There is no guarantee in the entire communication process. Therefore, we often say that connection-free protocols are not reliable. Of course, the Post Office will try its best to send the right-click to the destination. In 99% of the cases, the mail will arrive safely, but in a few cases there are exceptions. Connection-oriented protocols have significant advantages over non-connection-oriented protocols in terms of reliability. However, before establishing a connection, you must wait for the response from the receiver and confirm whether the information is transmitted, a response signal is required when the connection is disconnected, which increases the resource overhead for the connection protocol. For TCP and UDP protocols, apart from the source port and destination port, TCP also includes serial number, validation signal, data offset, control mark (generally referred to as URG, ACK, PSH, RST, SYN, FIN), window, checksum, emergency pointer, option, etc. UDP only contains length and checksum information. UDP datagram is much smaller than TCP, which means less load and more effective bandwidth. Many instant messaging software use the UDP protocol, which has a great relationship. TCP-the transmission control protocol provides connection-oriented and reliable byte stream services. Before the customer and the server exchange data with each other, a TCP connection must be established between the two parties before data can be transmitted. TCP provides timeout resend, discard duplicate data, test data, traffic control, and other functions to ensure data can be transferred from one end to the other. Www.2cto.com UDP-User Datagram Protocol is a simple datagram-oriented transport layer protocol. UDP does not provide reliability. It only sends the data from the application to the IP layer, but it cannot guarantee that the data can reach the destination. Because UDP does not need to establish a connection between the client and the server before transmitting the datagram, and there is no timeout and re-transmission mechanism, the transmission speed is very fast. If you use TCP or UDP, which of the following aspects does your program focus on? Reliable or fast? Tcp udp is two protocols. Simply put, the TCP connection requires confirmation from the other party, But UDP does not need confirmation from the other party to receive the packet. Therefore, the TCP connection is safer, however, generally, the stream media in the playing network uses the UDP protocol Transport Layer Protocol, which generally includes TCP and UDP. TCP ensures reliable data transmission, however, this will incur a lot of extra network overhead. UDP is unreliable, so the transmission efficiency is relatively high. The local end is only responsible for sending data, and it is not guaranteed whether the peer end can receive the data. For UDP, reliability can be achieved at the application layer.
What is the difference between "stream mode" and "data packet mode" in programming? 1. TCP stands for a metaphor for TCP. You have a reservoir in your house. You can pour water in it. There is a faucet in the reservoir. You can put the water in the pool through the faucet, then use a variety of containers (cups, mineral water bottles, pots and pans) to connect to the water. In the above example, pouring water several times into the pool is not necessarily related to taking the water several times. That is to say, you can only pour the water once and then pick it up 10 times. In addition, the amount of water in the pool will be less; the amount of water poured into the pool will increase, but it cannot exceed the pool capacity, the excess water will overflow. To combine TCP, the pool is like receiving a cache. Pouring Water is equivalent to sending data, and receiving water is equivalent to reading data. For example, if you send data to the other end through a TCP connection, you only call write once and send 100 bytes, but the other end can receive 10 bytes each time; you can also call 10 write times, with 10 bytes each time, but the other party can finish it at one time. (Assuming all data can be reached) However, the data volume you send cannot be larger than the recipient's receiving cache (Traffic Control). If you want to send excessive data, when the other party's cache is full, the extra data will be discarded. 2. UDPUDP and TCP are different. The sender calls several writes and the receiver must read the data with the same number of reads. UPD is based on packets. When receiving a message, only one packet can be read at most at a time. Messages and packets are not merged. If the buffer zone is smaller than the packet length, the extra part will be discarded. That is to say, if the MSG_PEEK flag is not specified, each read operation consumes one packet. 3. Why is this difference determined by the characteristics of TCP and UDP. TCP is connection-oriented. That is to say, during the connection continuity process, the data received by the socket is sent by the same host (hijacking is not considered). Therefore, you only need to know how much data is read each time. Www.2cto.com and UDP are connectionless protocols. That is to say, as long as you know the IP address and port of the acceptor and the network is reachable, any host can send data to the acceptor. At this time, if the data of more than one packet can be read at a time, it will be messy. For example, host A sends packets P1 and host B sends packets P2. If data of more than one packet can be read, data of P1 and P2 will be merged, such data is meaningless. In TCP/IP, TCP provides reliable connection services and uses three handshakes to establish a connection. First handshake: when a connection is established, the client sends the syn Packet (syn = j) to the server and enters the SYN_SEND status. wait for confirmation from the server. Second handshake: the server receives the syn packet, you must confirm the customer's SYN (ack = j + 1) and send a SYN Packet (syn = k), that is, the SYN + ACK packet. At this time, the server enters the SYN_RECV status; the third handshake: the client receives the server's SYN + ACK package and sends the ACK (ack = k + 1) Confirmation package to the server. After the package is sent, the client and server enter the ESTABLISHED status, complete three handshakes. After the three-way handshake is completed, the client and the server start to transmit data. In the above process, there are some important concepts: unconnected Queues: in the three-way handshake protocol, the server maintains an unconnected queue, this queue opens an entry for the SYN Packet (syn = j) of each client. This entry indicates that the server has received the SYN Packet and sent a confirmation to the customer, waiting for the customer's confirmation package. The connection identified by these entries is in the Syn_RECV state on the server. When the server receives the customer's confirmation packet, it deletes the entry and the server enters the ESTABLISHED state. Backlog parameter: Maximum number of unconnected queues. SYN-ACK retransmission times the server sends the SYN-ACK package, if the customer does not receive the confirmation package, the server for the first retransmission, wait for a period of time has not received the customer confirmation package, for the second retransmission, if the retransmission times exceed the maximum retransmission times specified by the system, the system deletes the connection information from the semi-connection queue. Note that the waiting time for each retransmission is not necessarily the same. Semi-connection survival time: the maximum time for the semi-connection queue to survive, that is, the maximum time for the service from receiving the SYN packet to confirming that the message is invalid, the maximum waiting time of all retransmission request packets. The semi-join survival time is also called Timeout time and SYN_RECV survival time. ========================================================== ============================== Now, let's look at a complete process. On a TCP socket, how does the system call connect to establish a connection to the peer end. Let's take the test environment 172.16.48.2 as an example to initiate a connection request to port 5002 of 172.16.48.1. Step 1: 172.16.48.2 initiate a connection request to 172.16.48.1, send a SYN segment, specify the destination port 5002, and advertise its initial serial number (ISN, a 32-digit random number generated by the protocol stack ), set the confirmation sequence number to 0 (because no peer data has been received), and notify yourself that the sliding window size is 5840 (the peer side is 5792, which seems to be a problem, to be further checked), the window expansion factor is 2 (in the first option), and the maximum length of the advertised message segment is 1460 (local area network ), the following is the data content (the Ethernet header of the link layer and the IP address header of the network layer): www.2cto.com data content meaning basic header 80 0e source port (32782) 13 8a destination port (5002) 00 00 07 bc initial NO. ISN 00 00 00 00 confirm no. a Header Length 0 02 flag, SYN = 1 16 d0 sliding window size (5840) 64 9e checksum 00 00 emergency pointer TCP option 02 04 05 b4 Max The message segment length (1460) 04 02 allows the SACK 08 0a 00 0a 79 14 00 00 00 00 timestamp (0x000a7914) and the echo timestamp (0) 01 placeholder. 03 02 window expansion factor (2) Step 2, 172.16.48.1 receive the request packet, check the flag bit, and find SYN = 1, think this is a request to initialize the connection, respond to this SYN, at the same time, it also sends its own SYN segment (that is, both ACK and SYN are set ). Because SYN occupies a sequence number (and the FIN also occupies a sequence number ). Therefore, confirm that the serial number is set to ISN plus 1 of 172.16.48.2 (that is, 172.16.48.1 expects to receive the first serial number of the next package from 172.16.48.2 as 0x07bd. At the same time, we also need to announce our initial sequence number, sliding window size, window expansion factor, maximum packet segment length, etc. The following is the data content: data content description basic TCP Header 13 8a source port (5002) 80 0e destination port (32782) 98 8e 40 91 initial serial number ISN 00 00 07 bd confirmation serial number (peer ISN + 1) a header length 0 12 flag, ACK = 1, SYN = 1 16 a0 sliding window size 65 d7 checksum 00 00 emergency pointer TCP option 02 04 05 b4 Maximum packet segment length (1460) 04 02 allow SACK 08 0a 00 3c 25 8a 00 0a 79 14 timestamp (0x003c258a), Echo timestamp (000a7914) 01 placeholder 03 02 window expansion factor (2) step 3: 172.16.48.2 confirm the SYN segment from 172.16.48.1. At this point, the TCP three-way handshake protocol is complete, and the connection is established at 172.1 6.48.2 when receiving SYN segments, change the status of the corresponding socket from TCP_SYN_SENT to TCP_ESTABLISHED to enter the connection establishment state. The following figure shows the data content: www.2cto.com data content meaning 80 0e source port (32782) 13 8a destination port (5002) 00 00 07 bd No. (Not ISN anymore) 98 8e 40 92 Confirmation No. (peer ISN + 1) 8 header length (8*4 = 32, with 12-byte options) 0 10 logo, ACK = 1 05 b4 sliding window size (1460, is there a problem? To be confirmed) a5 8a checksum 00 00 Urgent Pointer 01 placeholder 01 placeholder 08 0a 00 0a 79 14 00 3c 25 8a timestamp (0x0a007914), Echo timestamp (0x003c258a) ========================================================== ===============================7. Briefly describe the TCP three-way handshake process, it also explains why the three-way handshake TCP three-way handshake is initiated through the three-way handshake. The purpose of the three-way handshake is to synchronize the serial number and confirmation number of both parties and exchange the TCP window size information. The following steps provide an overview of how client computers normally contact server computers: 1. the client sends a TCP packet with a SYN position to the server, it contains the initial serial number x of the connection and the size of a window (indicating the buffer size of the incoming segment sent from the server on the client ). 2. after receiving the SYN Packet sent from the client, the server sends a TCP packet with both SYN and ACK positions to the client, it contains the selected initial serial number y, the confirmation of the client serial number x + 1, and the size of a window (indicating the buffer size of the incoming segment sent from the client on the server). 3 .. after the client receives the SYN + ACK packet returned by the server, it returns an ACK packet with the Confirmation No. y + 1 and No. x + 1 to the server. A standard TCP connection is complete. TCP uses a similar handshake process to end the connection. This ensures that both hosts can complete transmission and that all data is received by the TCP Client Flags TCP Server 1 Send SYN (seq = x) ---- SYN ---> SYN Received ed 2 SYN/ACK Received ed <--- SYN/ACK ---- Send SYN (seq = y), ACK (x + 1) 3 Send ACK (y + 1) ---- ACK ---> ACK Received, Connection Established w: ISN (Initial Sequence Number) of the Client x: ISN of the Server www.2cto.com ==================================== ==================================== handshake stage: sequence Number direction seq ack 1 A-> B 10000 0 2 B-> A 20000 10000 + 1 = 10001 3 A-> B 10001 20000 + 1 = 20001 explanation: 1: A initiates A connection request to B, initialize the seq of A with A random number, which is assumed to be 10000. At this time, ACK = 0 2: After B receives the connection request of A, it also initializes the seq of B with A random number, suppose it is 20000, which means that I have received your request, and the data stream of my side starts from this number. ACK of B is the seq of A plus 1, that is, 10000 + 1 = 10001 3: After A receives A reply from B, its seq is the seq of its previous request plus 1, that is, 10000 + 1 = 10001, meaning: I have received your reply, and my data stream starts from this number. A's ACK at this time is B's seq plus 1, that is, 20000 + 1 = 20001 data transmission phase: seq ack size 23 A-> B 40000 70000 1514 24 B-> A 70000 40000 1514 + 41460-54 = 41460 54 25 A-> B 70000 70000 + 54-54 = 1514 26 B-> A 70000 41460 + 1514-54 = 42920 54 explanation: www.2cto.com 23: B receives seq = 40000, ack = 30000, size = 1514 packets from A 24: So B sends A packet to A, telling B, I have received your last package. B's seq is filled with the ACK of the packet it receives. ACK is the SEQ of the packet it receives plus the packet size (excluding the Ethernet protocol header, IP header, and TCP Header ), to confirm that all data sent by B has been received. 25: when receiving A 41460 seq packet sent by B, A sees 41460, which is exactly the size of the seq of its last packet plus the package, the last packet sent has arrived safely. So it sends another packet to B. The seq of the packet being sent is also filled with the ACK of the packet it received, and ACK is filled with the seq (70000) of the packet it received plus the size (54) of the packet, that is, ack = 70000 + 54-54 (all headers are long and there are no data items ). 26: same author T.C.