On the reading of "graphic Tcp-ip"

On the reading of "Graphic TCP/IP"

Tcp / ip

In recent days, read the "Graphic TCP/IP", the harvest is very much, remember to read Stevens in school, "TCP/IP detailed" when that is a swallowed, not seriously see also can not go on. When you have time to read the "TCP/IP detailed", it is estimated to have a lot of resonance.

Now feel that, to be more thorough understanding of TCP/IP, but also need to have server programming experience, the school should also open "socket programming" related courses, preferably the same teacher teach, you can chuanjiang, otherwise light theory is not actual combat is showy, and it is not easy to really understand the TCP/IP protocol.

TCP/UDP List

Only a more thorough understanding of the TCP/UDP to know why TCP is called Transmission Control Protocol, UDP called User Packet protocol. TCP in the back to help you do a lot of things, connection management, save timing, time-out retransmission, congestion control, flow control; Through the MSS automatically help you do the Shard, in order to reduce the transmission of router shard consumption (IPV6 router is not fragmented), which is called Transmission Control Protocol, highlighting the word "controlling". And UDP does nothing to help you do, do not guarantee the timing, do not do time-out retransmission, is the need for upper-level protocol to ensure that the user to write rules, which is the first U (user) meaning, and UDP does not have MSS, so one-time send the data is best not too much, so as to avoid fragmentation caused performance loss. That's why UDP calls the user Packet protocol, and when it comes to packets, it's about TCP and UDP connection-oriented and non-connected.

We know that TCP is connection-oriented, and UDP is not connected, which directly causes TCP to connect to the server through three handshake, if the server port is not known to TCP, but UDP is not the same, do not know the situation of the server segment, even if the server is not in line, the client sends the data.

In [22import socketIn [23]: s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)In [24]: s.sendto("hello world",("127.0.0.1",9999))Out[2411

There is no server, we send data, sendto () still return, if you do not know, this will surprise you, this also shows that UDP does not do packet confirmation.

TCP transmission is streaming data, that is, there is no fragmentation in the middle, which leads to the sticky packet problem we often have, so we need to packet and package, the common is the byte length + data, such as WebSocket. That is to say, we accept one time, it may be the data collection that the other party sends after many times, may also be the partial data that sends once, this is possible, cannot assume which kind of situation. It reminds me of the simple socket client that I used to go to school, the server program, all of them are a round, we do not have a packet unpacking is not normal? This is to say that the Linux recv system is called.

int recv (SOCKET s, char far *buf, int len, int flags);
Recv execution process (from online)
1.RECV wait s send buffer data sent complete, if there is a network error in the middle, the recv function returns SOCKET_ERROR

2.RECV checks the accept buffer of S, if the accept buffer has no data or
is receiving data , recv waits until the data is accepted. When the acceptance is complete, recv will copy the data from the s accept buffer into BUF (the buffer data may be greater than buf length, so the recv needs to be called multiple times. Recv is just copy data, really accept the data is the underlying protocol to complete)

Well, that's good to understand, because our clients are usually send again recv, and then send the completion of recv will wait, and we have a small amount of data, each interval is relatively large, so there is data, Recv returned. Of course this is also a hidden danger, send data large, once recv may not accept, that need to recv, then need to seal the package, otherwise you how to know when to return.

In the case of HTTP, the server packets are content-length and chunked encoded to allow the browser to parse the data. Of course http1.0 In fact content-length is necessary, because each time after the data is sent, the server will close, the client recv will return 0, when it will know the end of the data, that is, close as the EOF flag, a bunch of downloads are through this way, so there will be no sticky bag.

And UDP will not appear sticky packet, receive will definitely be able to receive the data sent, the world instantly clean, this is also the concept of udp** packet * *, one packet, received is a complete packet.

Checksum

The TCP/IP test and verification algorithms are similar, that is, the so-called

Inverse Code Summation

The process is as follows

1. Officer test and set to 0
2. Convert data to 16-byte shaping, less than 0, sum (with 32-bit addition, add high 16-bit and low 16-bit, and add the possible carry and low 16-bit)
3. and seek Counter-

Finally the sender officer and replaces the result of the negation, sends the data to the recipient, the recipient ignores the first step using the same algorithm, if the final result is not 0, the packet will be discarded.

Preface a bit, so with Golang simulated the next

//Checksum algorithm//For each 16 bits (2 bytes) of binary inverse code summation, the meaning of the inverse code summation is to sum each 16 bits, and then the resulting and to the inverse codefuncCheckSum (data []byte)uint16{//paddingAll: =Len(data)/2    ifAll * *<Len(data) {all++ data =Append(Data,0)} U16: = (*[0XFFFF]uint16) (unsafe. Pointer (&data[0])) [: all]varSumUInt32     for_, U: =RangeU16 {sum + =UInt32(u)} sum = (sum >> -) + (Sum &0XFFFF)//Put high carry, add to low eight bitssum + = Sum >> -                   //Previous step may have rounding    return(uint16) (^sum)}funcMain () {check: = Make([]byte,2) Data: = []byte("TCP/IP checksum test1")//First as the checksum fieldAll: = []byte(string(check) +string(data)) Sum: = CheckSum (All) fmt. Println (all, sum)//Checksum write first    Copy(All, (*[2]byte) (unsafe. Pointer (&sum)) [:]) fmt. Print (All, CheckSum (All))}

Results:

[0 0 116 99 112 47 105 112 32 99 104 101 99 107 115 117 109 32 116 101 115 116 49] 22732
[204 88 116 99 112 47 105 112 32 99 104 101 99 107 115 117 109 32 116 101 115 116 49] 0

We found that at the end of the 0, we have no problem with the algorithm, as to why it should be 0, the small partners to think about it.

TCP Serial number and sliding window

The following is a seq,ack of TCP, when the two sides of the communication seq started randomly generated,
Suppose a starts Seq100,ack 1 and sends the data size 100

Communication	seq	ack	size
A->b	100	1	10
B->a	200	111	0
A->b	111	201	1000
B->a	201	1112	0

1.a->b initial random seq 100,ack 1, sending data 10 bytes
2.b->a Initial sleep seq200, tell a next send 111, the preceding data are received, because B is just the response packet size 0
3.a->b A receives a response from B, sees an ACK of 111, knows that the previous 10 itself has been successfully sent, so SEQ is 111, sends 1000 bytes, and responds B next start sending 201
4.b->a ack for 1000+111+1, tells A to start sending from 1112 next

As long as the other party responds to the ACK, then the data before the ACK is received successfully, this is the other side can be the corresponding buffer of their own data to be emptied, or need to be saved to be re-transmitted. Because the throughput is a bit low each time a single transfer, TCP refers to a sliding window, that is, you can send a W packet continuously without explicitly receiving an ACK, W is the size of the sliding window. Due to the reference to sliding windows, some ACK loss is not related, as long as the subsequent ACK acknowledgement is received on behalf of the previous data has been successfully received.

Csma/cd

Communication professional to CSMA/CD certainly is not unfamiliar, I found that teachers especially like to say this thing, but I always do not understand the use of this thing? In fact, CSMA/CD is used to share the network , that is, through the hub or coaxial cable connections such as the total Linetype or star topology, because this thing we have never seen (outdated), because of the need for conflict checking is half-duplex communication . When the switch comes out, CSMA/CD is eliminated and full-duplex communication is realized through port forwarding on the switch. I don't know if it was the teacher's problem or I was too weak to understand the application scenario now. Now the wireless is also half-duplex, is a modified version of CSMA/CD, called Csma/ca.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

On the reading of "graphic Tcp-ip"