"TCP/IP detailed" reading notes

1 Overview of TCP/IP 1.1 TCP/IP protocol

Commonly referred to as TCP/IP protocol refers to the "TCP/IP protocol Family", which includes TCP, IP and other network protocols, including a set of many network protocols. The TCP/IP protocol can also be considered an implementation of the OSI model (but it has only four layers). The structure from the bottom to the top is shown in the following figure.

Figure 1-1 TCP/IP protocol stack

The link layer is primarily responsible for the drive of the physical device.

The network layer mainly deals with grouping (which can simply be considered as the transmission message segment) activity in the network. such as grouped route selection.

The transport layer provides "end-to-end" communication primarily for applications on both ends of the transport.

the application layer is responsible for processing this data. 1.2 TCP/IP Transfer process overview

First, the Physical address (MAC address) of any host in the world is not the same. At the link layer, this physical address enables the transmission of data. In fact, the local area network is directly by the MAC address for data transmission.

and thousands of internet-connected LANs are combined to form the Internet. The LAN and the LAN are connected by one or more routers. Its topological structure can be easily understood as the following diagram (which is actually more complex than this). Links each router maintains a justification table. This routing table can simply assume that you have all the direct host IP addresses and MAC addresses of the subordinate, plus a default table (multiple) pointing to the next routing device.

Figure 1-2 Internet topology structure diagram

1. Send data from BSDI to Sun

In fact, there is a routing table on each host. On Windows we can view it through the route print command. After the BSDI IP layer receives the upper-level data, it first searches the native routing table. Discover the destination IP address 104.252.13.33 and yourself on the same network (104.252.13.0). So BSDI issued an ARP broadcast, Sun received the broadcast after the discovery of its own IP and ARP packet query IP address exactly match, then send back a packet containing its own MAC address. With the destination MAC address, BSDI can send the packet to sun. In fact, the ARP cache exists in BSDI (that is, BSDI already knows the MAC address of the peer). The IP address is redundant for data transmission. Local area network is to rely on MAC address communication.

2. Send data from BSDI to 192.48.96.9

You can see that this IP address 192.48.96.9 is not actually in any of the local area networks in Figure 1-2. Instead, it exists in the Internet on the outside network.

Similarly, BSDI searches the native routing table and finds that the IP address does not exist in its own routing table. The packet is then sent to the default table. The default table points to the Router sun (Sun is the host but also serves as the router role). Therefore, a physical layer packet with a destination IP address of 192.48.96.9 but a MAC address that is Sun's Mac is constructed in the BSDI link layer. Because the MAC address is the root of the transmission, IP packets are sent to sun.

After receiving the message, Sun also traverses its own routing table and discovers that the corresponding table does not exist and sends the IP packet to the router NetB that corresponds to its default table. The difference here is that between sun and NetB is connected via slip, and the packet from Sun to NetB does not involve a MAC address. Because the transfer between them is made by slip protocol. As can be seen from here, a packet from the source host to the destination host, the intermediate experience of the transfer Protocol is diverse. However, the destination IP address is always intact.

NetB after the IP packet is received. As well as traversing its own routing table, there is still no matching table found, so the IP packet is sent to the router gateway specified by the default table. And so on

Suppose a node assumes a 192.48.xx.xx table in the routing table. This class of router will find the IP packet destination IP address 192.48.96.9 network number and the destination network number is 192.48. Therefore, the IP datagram is sent to the router that the table points to. Assume that the IP address of the router is 192.48.1.5 (although it seems that the end of the general subnet should be 1), that is, the following figure of Router 3.

Access to the information can be found that the IP address can be divided into a, B, C, D, e five categories. As shown in the following figure.

Figure 1-3 IP address sub-classification

192.48.1.5 is obviously a class B address. The Class B address network number is clearly specified in the above image. IP routing also says that the network number needs to be matched. This network number is this network number. Here after my repeated thinking research, "TCP/IP detailed Volume One" in the third chapter on this part of the content description, said network number should be accurately understood as "network number + host number in the subnet number."

Router 3 searches its own routing table, finds that it does not exactly match the table (network number + host number), but has a network number matching address 192.48.64.6 Router 4 (network number matching requires the participation of the subnet mask), so the IP data packets to Router 4. The network number matching process is as follows (assuming that the subnet mask for Router 3 is ffff40)

Router 4 also sends IP data packets to router 5 by matching the network number.

Router 5 searches its own routing table to find an exact match for the table. The IP packet is then sent to the B host with IP address 192.48.96.9. This data is transferred correctly.

The matching path is shown in the following figure.

Figure 1-4 IP Packet Routing

Here are a few things to explain.

1, please do not connect the router here with the home router. Home Router Management is the private IP, and here the IP is a public IP, I think these two types of IP is very different.

2,ip datagrams do not always exist in the network, the IP header has a eight-bit-length TTL (Time-to-live), and its general implementation is minus 1 per router, and when it is zero, the router drops the IP packet.

2 IP protocol 2.1 IP message Format

The IP protocol is the core of the entire TCP/IP.

The format of the IP datagram is shown in the following figure

Figure 2-1 IP Datagram format

Where TOS is now ignored, but it must have 0 after 4 bits.

The 16-bit total length represents the length of the entire IP datagram.

The identity field identifies each datagram sent by the host. Usually 1 is added to each data sent. This is essentially marking each data IP message. After the IP packet is fragmented, the router or host can determine which IP message the IP shard belongs to by this flag.

Because of the possible presence of shards in the composition of the IP message transmission, the 3-bit flag bits and slice offsets act on the Shard and assembly.

The TTL indicates the time that the datagram can exist on the network. 2.2 Subnet mask

The subnet mask and IP address are the "and" operations that derive the subnet where the IP resides. such as 140.252.4.5, the subnet mask is 255.255.255.0. After doing the "and" budget, the subnet is 140.152.4.0. This is how the router matches the network number of the routing table as previously mentioned.

3 UDP

Cond

4 TCP handshake, data transfer and wave 4.1 TCP message Format

The header of the TCP protocol is shown in the following figure.

Figure 4-1 IP Datagram format

A 32-bit serial number, the ISN number, indicating the number of the data being sent (the first data pointing to the message). The isn number that is logged when the connection is established actually identifies the connection (the starting isn+ source IP and the source port, which in fact uniquely identifies any one connection). The number of the data that is sent later begins with the start of the isn number. Theoretically this start isn should be random, and any two will not be repeated, this and ordinary random is different, so TCP has its own set of random algorithm, generally may be every 0.5s plus 64000 or each set up a connection also add 64000, about 9.5 hours after the round.

There are actually two problems here.

1, it is entirely possible for a connection to send data in the same way as the start of the next connection. However, with the IP header source IP and TCP header source port, two IP messages can be completely differentiated. (This simple question bothered me for a long time). The reason why TCP needs a random starting isn is not to differentiate between a host and a different host (in fact, they are naturally differentiated from the source IP). Instead, the two hosts are distinguished, and the source port has the same two connections. This avoids the delay of an IP datagram being sent, resulting in an incorrect interpretation of it (page 176th of the TCP\IP-detailed volume one).

In fact, people who know something about the state of TCP at the end of the time_wait will still be surprised: the 37th page of the UNIX Network Programming volume 1 clearly states that Time_wait has two roles, one of which is "it allows old, repetitive sections to fade out of the network." The random selection from the above-mentioned starting isn (hereinafter referred to as the SYN number) should be the same.

Here is an analysis: assuming that the previous connection A's isn number because the transmission of the data by 0 to 11, then the connection is interrupted. Immediately thereafter reconnect (assuming that the connection is immediately on), the connection to B (AB connection obviously does not exist at the same time, the same IP as the port can not be established at the same time there are two connections). Suppose B has a SYN number of 10. A 11th message was delayed, but the a connection was turned off (because it was closed because another resend of the 11th message was received), it may be received by the connection B, which is obviously a false reception. What is the probability of the occurrence of this situation?

Suppose AB establishes the interval between t,ab without any connection between the establishment, here according to Isn0.5s Plus 64000, to establish a connection plus 64000 algorithm, then AB SYN has the following relationship (assuming within the same 9.5h period)

syn_a+64000* (t/0.5+1) =syn_b (t>0)

The most extreme situation is that a at a certain speed (assuming v) to send data, and B connection has been idle, B has been expecting a syn_b+1 IP packet. It is necessary to meet the previous situation

Because the ISN unit is byte, the time unit is good, 128000byte/s count each byte of the start and end character, for 128m/bs. Requires a 1280 gigabit speed. In fact, due to the presence of IP and TCP headers, the 128mb/s rate is not enough. So this situation is almost impossible.

Things are getting more and more complicated, we know that the time of the well is a cycle, then the next cycle is likely to appear in the network two of the same isn packets. Assuming a connection is based on the SYN number ISN0, 9.5h does not send the data at all, sends the data at the end of the 9.5h and terminates the connection, assuming that one of the packets is isn0+64000+1 and is delayed. Immediately after the B connection establishes the SYN number exactly isn0+64000, it sends a data immediately, then its first data byte is isn0+64000+1. This has the potential to cause misreading on the end. This situation requires a TCP connection that lasts longer than 9.5 hours and is a small probability event. But a small probability event may also occur.

Then the foolproof approach should be to try to avoid two same-size packets that exist in the network at the same time.

We know that there is a field TTL (Time to live) in the IP header. This means that a message must have been dropped by the link after the TTL time has been issued. However, it should theoretically be the TTL parameter of time, which is difficult to achieve with "time", and its general implementation is that the TTL is reduced by 1 per router and discarded by 0 o'clock. Therefore, the lifetime of the message can only be estimated, the MSL (the longest time the message survives) came into being, the parameter exists in the host system and is just an estimate of the real MSL. The MSL cannot be accurately estimated because the time required for the router to forward the IP message and the time of the message on the link cannot be accurately estimated. If the TCP active termination connection is designed to last the time_wait state of the 2*MSL time at the end of the connection, it can be inferred that the isn number is repeated every 9.5 hours, as long as the actual MSL is less than 9.5h,b connected at a connection termination 2*msl (2msl< 9.5) before it can be established, at this point, all IP packets of a must have vanished. Assuming that sender a receives B, the time of 2 *MSL is sufficient to ensure that the end a end receives the B-end fin signal and then sends an ACK signal.

think carefully, with time_wait, the random syn number seems redundant. Because it has been found from above that it is difficult to avoid completely. However, the MSL is generally designed to be 2min or 30s, etc., and the MSL

is clearly stated in the previous analysis