Calculation calendar: 7E3 year af month 5E day. Weather: sunny. First day of my internship at Chrome.
I finally got out of school and started my internship in Chrome. It was a good day. The Internet was fine, no bag loss occurred, and the reality was not as bad as the teacher said.
The workbench of the elder is also too dazzled cool, do not know the classmate that practice in FireFox namely how, IE that classmate, estimate is manual operation! Ha ha!!!!!
Today, I sent a lot of packets with this workbench, which is much faster than the manual operation of the packets in school. But the foundation can not be forgotten. Today, there is nothing to record, so let’s review the basis of TCP packets.
TCP: Transmission Control Protocol: a transport layer Protocol designed to provide a reliable byte stream transport channel over complex networks (over unreliable IP protocols).
Reliability means data integrity, that is, when the network is connected, data from the application layer can be completely sent to the application layer of the other party without any possible errors.
So how to eliminate errors, for the packets that did not reach the other party (including the packets that may have arrived but the other party did not return the confirmation), continue to resend! Until they acknowledge receipt.
OK, let’s go over the basics.
composition
First, review the composition of the message:
A complete packet contains the preceding information and has the following functions in sequence:
| area | Take up the byte | meaning |
|---|---|---|
| Source port | 16 | TCPThe port number of the process where the channel resides, which is also the number of my workshop. |
| Destination port | 16 | TCPThe port number of the process on the other side of the channel is probably the same as mine. |
| The serial number | 32 | The serial number of the first byte of the data carried in the current packet. The peer party will combine the data according to the serial number. The serial number is not important. |
| Confirm the serial number | 32 | Confirm indicates that the packet before the serial number is received successfully. |
| Data migration | 4 | Due to theTCPHeader length is not determined, the other side can know according to this fieldTCPHead length. |
| Keep a | 6 | Not currently in use, set0Can. |
URG |
1 | The emergency flag bit indicates whether the message needs to be processed first, mainly for its own side of the process. |
ACK |
1 | It indicates that the current packet is an acknowledgement packet, indicating that the data before the acknowledgement sequence number has been received. |
PSH |
1 | Push flag notifies the process that it will push data out of the cache. |
RST |
1 | The channel reset flag notifies the other party of the resetTCPChannel. |
SYN |
1 | The synchronization flag bit notifies the other party that it is enabledTCPChannel. |
FIN |
1 | The end flag notifies the other party that the request is closed one-wayTCPChannel. |
| window | 16 | Tell the other person how much of the cache you currently have availableTCPA condition in which a message is not accepted because there is no buffer. |
| The checksum | 16 | Verify the integrity of current data, generated by your own side and verified by the other side. |
| Pointer to an emergency | 16 | withURGUsed in conjunction, indicates the size of the emergency data. |
| options | Not fixed | Some other options forTCPSome supplements after development. |
| fill | Not fixed | makeTCPThe length of the header is32An integer multiple of. |
| data | Not fixed | Data that needs to be transferred. |
There are many options in the content, next time mainly review this piece, here first.
Connect and release
Since TCP is represented as a channel, the connection and release of the channel is of course the most important.
※ Three handshakes.
The network is a complex environment, a stable channel requires both parties to know that the other party has sent and received their own ability, this is the origin of the three-way handshake.
First handshake (client request to establish a connection) :
| * | Client sending capability | Client reception capability | Sending capability of the server | Reception capability of the server |
|---|---|---|---|---|
| The client | x | x | x | x |
| The service side | Square root | x | x | Square root |
- Client: Although the client sends the request, it is not clear that it has actually sent the message to the server, so the client is not aware of its own capabilities and those of the other side.
- Server: After receiving the packet, the server knows that the client can send the packet and that it can receive the packet.
Second handshake (the server receives the packet, confirms the connection, and requests the connection) :
| * | Client sending capability | Client reception capability | Sending capability of the server | Reception capability of the server |
|---|---|---|---|---|
| The client | Square root | Square root | Square root | Square root |
| The service side | Square root | x | x | Square root |
- Client: If the returned packet passes the authentication, the client can send it and the server can receive it. If the packet is received successfully, the client can receive it and the server can send it.
- Server: Like the first handshake, the server sends a packet but does not know whether the packet arrived correctly.
Third handshake (the client receives the packet and confirms the connection) :
| * | Client sending capability | Client reception capability | Sending capability of the server | Reception capability of the server |
|---|---|---|---|---|
| The client | Square root | Square root | Square root | Square root |
| The service side | Square root | Square root | Square root | Square root |
- Client: During the second handshake, the client confirms the capabilities of both parties,
- Server: Similar to the client for the second handshake, if the packet passes the authentication, the client is able to send and receive the packet.
At this point a stable channel has been established.
※ Wave four times
The establishment of the channel needs to consume computer resources, so when the data transmission is completed, how to release, is also an important part.
How to close the channel correctly is the problem we need to think about.
The closure of a channel, as well as the opening, it takes two to tango, need to be confirmed by both sides.
- First wave: Client requests to close the connection.
- Second wave: The server acknowledges the client’s shutdown request.
- Third wave: the server requests to close the connection.
- Fourth wave: The client acknowledges the shutdown request from the server.
After four waves of the hand, the channel is destroyed with the knowledge of both parties, without one destroying the other but still existing, and the computer resources are freed accordingly.
So why can’t we just do it three times, like we did with the channel?
When the client closes the channel, it simply means that the client does not send data, while the server can continue to send data, and the client can still receive data.
summary
The opening and closing of channels are actually the same, requiring 4 steps
- One end requests to turn on/off
- Confirm that the other end is on/off
- The other end requests to turn it on/off
- Confirm one end is on/off
However, in the process of opening the channel, step 2 and step 3 are combined.
OK sorted almost, these are the basic, but also the most important part, although the previous workbench will help to do these steps, but in case of machine failure, as the top student of TCP College, I want to make sure that the data can always reach the server!!
Right! There are still some things I haven’t used in the workbench of my predecessors. I haven’t fully understood the information on the big screen, but I have got a general idea, and I will study it carefully tomorrow.
reading
- TCP workbench