Sharp weapon tcpdump

preparation

Web The server IP( Alibaba cloud's intranet IP:172.17.51.219:443)  
 Client browser  IP:114.242.250.59

Sign a ( Commonly used )

P push, Refresh output now buffer
.  Confirm response ACK
F  Confirm end 
S  Request synchronization     

step ：

1 Server side shell In the implementation of tcpdump Start listening

tcpdump tcp -i eth0 '((host 172.17.51.219 or 114.242.250.59) and port 443)' -nn -S

Parameter interpretation ( More parameters man once )

tcp     :  Monitor only tcp Protocol packet 
-i eth0 :  Monitor network card  eth0  On the traffic ( My host passes  eth0  Communication with external network )
-nn     :  With ip:port Instead of the mnemonic display form    Otherwise, something like  www.example.com:https  form 
-S      :  Display in absolute value   Send the serial number , Confirm serial number , Easy for visual observation  SYN  And  ACK  The relationship between , By default, it is displayed as a relative value 
'((host 172.17.51.219 or 114.242.250.59) and port 443)' ：  Clearly specify monitoring  host:172.17.51.219  And  host:114.242.250.59  Through between  443  Packets received or sent 

2 Client browser access web The server

    https://www.example.com?foo=foo

3 Observe shell After the end output

After the handshake data is detected ,ctrl + c Stop monitoring

[[email protected] ~]$>tcpdump -i eth0 '((host 172.17.51.219 or 114.242.250.59) and port 443)' -nn -S
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:51:40.965707 IP 114.242.250.59.41032 > 172.17.51.219.443: Flags [F.], seq 3249586170, ack 137328987, win 2061, options [nop,nop,TS val 555445081 ecr 2928319486], length 0
13:51:40.965838 IP 172.17.51.219.443 > 114.242.250.59.41032: Flags [F.], seq 137328987, ack 3249586171, win 235, options [nop,nop,TS val 2928333454 ecr 555445081], length 0
13:51:40.966228 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [S], seq 1328522649, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 555445081 ecr 0,sackOK,eol], length 0
13:51:40.966266 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [S.], seq 466300160, ack 1328522650, win 28960, options [mss 1460,sackOK,TS val 2928333455 ecr 555445081,nop,wscale 7], length 0
13:51:40.966630 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [S], seq 3150370905, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 555445081 ecr 0,sackOK,eol], length 0
13:51:40.966650 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [S.], seq 3538757503, ack 3150370906, win 28960, options [mss 1460,sackOK,TS val 2928333455 ecr 555445081,nop,wscale 7], length 0
13:51:40.986348 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [.], ack 3538757504, win 2064, options [nop,nop,TS val 555445117 ecr 2928333455], length 0
13:51:40.986539 IP 114.242.250.59.41032 > 172.17.51.219.443: Flags [.], ack 137328988, win 2061, options [nop,nop,TS val 555445117 ecr 2928333454], length 0
13:51:40.991849 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466300161, win 2064, options [nop,nop,TS val 555445118 ecr 2928333455], length 0
13:51:40.994419 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [P.], seq 3150370906:3150371429, ack 3538757504, win 2064, options [nop,nop,TS val 555445118 ecr 2928333455], length 523
13:51:40.994460 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [.], ack 3150371429, win 235, options [nop,nop,TS val 2928333483 ecr 555445118], length 0
13:51:40.995615 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [.], seq 3538757504:3538760200, ack 3150371429, win 235, options [nop,nop,TS val 2928333484 ecr 555445118], length 2696
13:51:40.995621 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [P.], seq 3538760200:3538760565, ack 3150371429, win 235, options [nop,nop,TS val 2928333484 ecr 555445118], length 365
13:51:40.996812 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [P.], seq 1328522650:1328523173, ack 466300161, win 2064, options [nop,nop,TS val 555445118 ecr 2928333455], length 523
13:51:40.996850 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [.], ack 1328523173, win 235, options [nop,nop,TS val 2928333485 ecr 555445118], length 0
13:51:40.997984 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [.], seq 466300161:466302857, ack 1328523173, win 235, options [nop,nop,TS val 2928333487 ecr 555445118], length 2696
13:51:40.997991 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [P.], seq 466302857:466303222, ack 1328523173, win 235, options [nop,nop,TS val 2928333487 ecr 555445118], length 365
13:51:41.024807 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [.], ack 3538760200, win 2026, options [nop,nop,TS val 555445154 ecr 2928333484], length 0
13:51:41.024809 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [.], ack 3538760565, win 2021, options [nop,nop,TS val 555445154 ecr 2928333484], length 0
13:51:41.029955 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466302857, win 2022, options [nop,nop,TS val 555445154 ecr 2928333487], length 0
13:51:41.029957 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466303222, win 2016, options [nop,nop,TS val 555445154 ecr 2928333487], length 0
13:51:41.032718 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [P.], seq 3150371429:3150371522, ack 3538760565, win 2048, options [nop,nop,TS val 555445155 ecr 2928333484], length 93
13:51:41.033098 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [P.], seq 3538760565:3538760839, ack 3150371522, win 235, options [nop,nop,TS val 2928333522 ecr 555445155], length 274
13:51:41.033172 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [P.], seq 1328523173:1328523266, ack 466303222, win 2048, options [nop,nop,TS val 555445156 ecr 2928333487], length 93
13:51:41.033374 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [P.], seq 466303222:466303496, ack 1328523266, win 235, options [nop,nop,TS val 2928333522 ecr 555445156], length 274
13:51:41.035404 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [P.], seq 3150371522:3150372299, ack 3538760565, win 2048, options [nop,nop,TS val 555445156 ecr 2928333484], length 777
13:51:41.035512 IP 172.17.51.219.443 > 114.242.250.59.41034: Flags [P.], seq 3538760839:3538761043, ack 3150372299, win 247, options [nop,nop,TS val 2928333524 ecr 555445156], length 204
13:51:41.065435 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [.], ack 3538760839, win 2043, options [nop,nop,TS val 555445192 ecr 2928333522], length 0
13:51:41.065920 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466303496, win 2043, options [nop,nop,TS val 555445192 ecr 2928333522], length 0
13:51:41.076415 IP 114.242.250.59.41034 > 172.17.51.219.443: Flags [.], ack 3538761043, win 2044, options [nop,nop,TS val 555445200 ecr 2928333524], length 0
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel

4 Data cleaning

One TCP Links are defined by two ends tcp := {sourceHost:port , dstHost:port }, So filter out from the output above Belong to the same tcp Of the link , Relatively complete transaction data , Such as choice {172.17.51.219:443 , 114.242.250.59:41033}
meanwhile , In the first part win part 、options part It is irrelevant for verifying three handshakes , It can also be shielded . After shielding the secondary information, the communication flow becomes clear .

[[email protected] ~]$>tcpdump -i eth0 '((host 172.17.51.219 or 114.242.250.59) and port 443)' -nn -S
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

 Time stamp                  The sender IP:port               The receiver IP:port            Sign a           Send sequence , Receiving sequence  ...   
13:51:40.966228  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [S],    seq 1328522649,  length 0
13:51:40.966266  IP  172.17.51.219.443      >  114.242.250.59.41033:   Flags [S.],   seq 466300160, ack 1328522650, length 0
13:51:40.991849  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [.],    ack 466300161,  length 0
13:51:40.996812  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [P.],   seq 1328522650:1328523173, ack 466300161,  length 523  
13:51:40.996850  IP  172.17.51.219.443      >  114.242.250.59.41033:   Flags [.],    ack 1328523173, length 0
13:51:40.997984  IP  172.17.51.219.443      >  114.242.250.59.41033:   Flags [.],    seq 466300161:466302857, ack 1328523173,  length 2696
13:51:40.997991  IP  172.17.51.219.443      >  114.242.250.59.41033:   Flags [P.],   seq 466302857:466303222, ack 1328523173,  length 365
13:51:41.029955  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [.],    ack 466302857,  length 0
13:51:41.029957  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [.],    ack 466303222,  length 0
13:51:41.033172  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [P.],   seq 1328523173:1328523266, ack 466303222,  length 93
13:51:41.033374  IP  172.17.51.219.443      >  114.242.250.59.41033:   Flags [P.],   seq 466303222:466303496, ack 1328523266, length 274
13:51:41.065920  IP  114.242.250.59.41033   >  172.17.51.219.443:      Flags [.],    ack 466303496, length 0
...

5 Analyze three handshakes

Interpret messages one by one in chronological order

13:51:40.966228 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [S], seq 1328522649,  length 0

The browser sends the creation... To the server TCP Link request , Send the serial number seq=1328522649( Logically 1328522649:1328522649 From the first 1328522649 From the first byte to the second 1328522649 end ),
Because the purpose of this package is to create TCP link , So the data section is not filled with content . therefore tcpdump Parse out the entity data part length=0
And this will be the first Flags Medium SYN Bit is set to 1, The other five ( Include ACK position ) Set to 0 ,
When the flag bit is in SYN=1 && ACK=0 when , Represents that this packet is a connection request message , tcpdump The tool will only put the flag bit other than 0 Partial analysis of is shown in [] in ,
For example, this flag bit [S]. Then the client enters SYN-SENT Sync sent state

13:51:40.966266 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [S.], seq 466300160, ack 1328522650, length 0

After the server receives the client connection request , Agree to establish a connection Return response message , At the same time, put the flag bit in SYN position 、ACK The position is 1(ACk The flag bit is represented by a symbolic dot ,SYN Follow ACK Put it all together [S.]), Other positions are 0
When SYN=1 && ACK=1 when , Indicates that this connection receives messages , At this time, the handshake has not been completed So the data length length=0
At this time, the server sends the confirmation serial number ack( Pay attention to this ack Not in the flag bit ACK), This ack The representative means , The server expects the sending sequence number of the next message from the browser ack Start , And this ack Equal to... In the message sent by the previous browser to the server seq+1. meanwhile , The server also sends data to the browser , So the sending serial number of the server seq=y( Here is 466300160)
representative , The server needs to retrieve the data from its output cache y Bytes are sent . At this point, the server process enters SYN-RCVD Sync received state

13:51:40.991849 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466300161,  length 0

After the browser receives the response message from the server , Verify the confirmation number of the server ack Whether it is equal or not (1328522649 + 1 = 1328522650) After passing the verification ,
The browser knows that the server has agreed to its connection request , At this time, the browser also sends an answer number to the server ack= The server .seq + 1 This step is to avoid the exception of the first request connection ,
here TCP Connection creation complete . The client process enters ESTABLISHED`` Connection established state . When the server receives the confirmation from the browser , Also enter ESTABLISHED state

13:51:40.996812 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [P.], seq 1328522650:1328523173, ack 466300161,  length 523

The browser sends the confirmation of connection request acceptance ack after , Start sending messages with data immediately ,
Sign a P Set to 1 representative , Output immediately buffer Send the data in to the server , Don't wait buffer The data in is accumulated to a certain scale and then sent ,
At the same time, this message should also carry ack= The server .seq + 1
At this time, the length of data sent by the browser is length = seq The border 1328522650:1328523173 The difference between the :523

13:51:40.996850 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [.], ack 1328523173, length 0
13:51:40.997984 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [.], seq 466300161:466302857, ack 1328523173,  length 2696
13:51:40.997991 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [P.], seq 466302857:466303222, ack 1328523173,  length 365
13:51:41.029955 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466302857,  length 0
13:51:41.029957 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466303222,  length 0
13:51:41.033172 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [P.], seq 1328523173:1328523266, ack 466303222,  length 93
13:51:41.033374 IP 172.17.51.219.443 > 114.242.250.59.41033: Flags [P.], seq 466303222:466303496, ack 1328523266, length 274
13:51:41.065920 IP 114.242.250.59.41033 > 172.17.51.219.443: Flags [.], ack 466303496, length 0
...

This part belongs to the communication of conventional data transmission and reception , In general, it's The server sends a message to the browser , It carries data , The browser returns a message , It means that the data you just sent has been received ,
Such a reciprocating cycle sometimes Sending and confirming messages may not be next to each other , This is because TCP The sliding window protocol .TCP Use acknowledgement and retransmission mechanisms , Reliable communication over unreliable transmission networks

about IM application , A service port can be connected to N Client ports for communication , Because the server-side process maintains a TCB(Transmission Control Block), It stores the data of each connection
Some important information of , such as TCP Connection table , Pointers to send and receive caches, etc …, Not for every one from the client TCP The connection is assigned a port .

Why does it take three handshakes to establish a connection , Not two handshakes ？

To prevent the invalid connection request message segment from being received by the server , So there's a mistake .

PS： Invalid connection requests ： If the connection request sent by the client to the server is lost , The client will send the connection request again after waiting for a response , here , The last connection request was 『 Invalid 』.

If a connection is established, only two handshakes are needed , The client doesn't change much , You still need to get the response from the server before entering ESTABLISHED state , The server enters after receiving the connection request ESTABLISHED state . At this point, if the network is congested , The connection request sent by the client fails to reach the server , The client will time out to resend the request , If the server receives and confirms the response correctly , Double convenient start communication , Release the connection when communication is over . here , If the invalid connection request reaches the server , Because there were only two handshakes , When the server receives the request, it will enter ESTABLISHED state , Waiting to send data or actively sending data . But the client has already entered CLOSED state , The server will always wait , This wastes the connection resources on the server side .

TCP Release of connection

TCP The release of a connection is slightly more complex than the creation of a connection , Usually A complete release process needs to exchange four groups of messages .

client tcpdump Monitoring results

[[email protected] ~]sudo tcpdump -i en0 '((host 39.106.58.35 or 114.242.249.148) and port 443)' -nn -S    
20:18:58.450967 IP 192.168.43.226.54739 > 39.106.58.35.443: Flags [F.], seq 1024508534, ack 2329885927, length 0
20:18:58.520988 IP 39.106.58.35.443 > 192.168.43.226.54739: Flags [F.], seq 2329885927, ack 1024508535,  length 0
20:18:58.521051 IP 192.168.43.226.54739 > 39.106.58.35.443: Flags [.], ack 2329885928, length 0

39.106.58.35 It is the external network of the server IP , Can be regarded as 172.17.51.219. Next, analyze the message

20:18:58.450967 IP 192.168.43.226.54739 > 39.106.58.35.443: Flags [F.], seq 1024508534, ack 2329885927, length 0

First , The client actively sends the connection release message to the server , Sign a F Set to 1,seq by 1024508534, After sending the message , The client from ESTABLISHED Get into FIN-WAIT-1 state ,( This step can carry data ).

20:18:58.520988 IP 39.106.58.35.443 > 192.168.43.226.54739: Flags [.],  seq 2329885927, ack 1024508535,  length 0

After the server receives the release message , Return confirmation to the client ack=1024508534+1, Consume one... At the same time seq=2329885927, After sending the confirmation message , The service side from ESTABLISHED Status entry CLOSE-WAIT state
here From client to server In this direction TCPL The connection is released in one direction (TCP It's full duplex communication , Information transmission is bidirectional ). in other words , The client has no data To send to the server ( Note that data cannot be sent , But you need to send ACK),
here TCP The connection is half closed (half-closed), But the direction of the server to the client TCP Still connected , You can still send data .

20:18:58.520999 IP 39.106.58.35.443 > 192.168.43.226.54739: Flags [F.], seq 2329885927, ack 1024508535,  length 0

here , The upper service process of the server ( for instance Nginx) Make sure there is no other data to send , Deliver notifications down the stack TCP Notify the opposite end ( That is, the client browser ), The flag bit F Set as 1,ack The following message is sent from the server to the client
ACK In the message ack Consistent values . At this time, the server enters LAST-ACK( Final confirmation ) state . Wait for the client to confirm .！！！ Be careful ！！！： The two next to each other share ack Value messages can be combined into one message ,F You can take the above ACK.
After receiving the confirmation from the client , Server access CLOSED state , Server access CLOSED The status should be earlier than the client

20:18:58.521051 IP 192.168.43.226.54739 > 39.106.58.35.443: Flags [.], ack 2329885928, length 0

After the client receives the confirmation from the server , The client from FIN-WAIT-1 Get into FIN-WAIT-2 state , Send a confirmation message at the same time , Must be ACK Set as 1, And then into TIME-WAIT state , wait for 2MSL(2 * MSL) after , The client enters CLOSED state .
When the client cancels this TCB( Transmission control block ) after , This time TCP The connection is really over .

This is the monitoring result of the corresponding server , For comparison

[[email protected] ~]$>tcpdump -i eth0 '((host 172.17.51.219 or 114.242.250.59) and port 443)' -nn -S
20:18:58.495313 IP 114.242.249.148.58188 > 172.17.51.219.443: Flags [F.], seq 1024508534, ack 2329885927,length 0
20:18:58.495476 IP 172.17.51.219.443 > 114.242.249.148.58188: Flags [F.], seq 2329885927, ack 1024508535,length 0
20:18:58.527252 IP 114.242.249.148.58188 > 172.17.51.219.443: Flags [.], ack 2329885928, length 0

sometimes , The client will suddenly lose contact due to some kind of failure , Such as power failure, network disconnection, etc , At this time, the server is still waiting for messages from the client , That's what we need TCP Keep alive timer (keepalive timer), Every time the server receives data from the client ,
Just reset timer, Usually two hours , If no data is received from the customer within two hours , Then send the detection message segment , every other 75 Seconds to send , if 10 No response after message segments , The server closes the connection .
There's one more thing to note , Both the client and the server can perform active shutdown , But it is usually the client , Examples of active shutdown by the server are :HTTP1.0

a key

a key

• tcp After each message of is sent, it needs to be confirmed ( stop it - Waiting for agreement ).
• As I understand it : A complete TCP Connection creation release process At least need 6 A package ( This is wrong , See the explanation below ).
• After reading a good article, it will give people a sense of enlightenment , But you have to stop it first , To open up .

Explain the above ：6 A bag means you need to wave 3 A package , instead of 4 A package , I think I need three bags because I think when waving F+ACK It can be combined . But that's not the case .

Why does it take four waves ?

When the connection is closed , When receiving from the other party FIN Message notification , He just said that the other party has no data to send to you , But not all your data has been sent to the other party .
So you can't turn it off right away socket, That is, you may also send some data to each other after , Sending FIN Message to the other party to indicate that you agree to close the connection now ,
So when waving ACK and FIN In many cases, messages are sent separately .

Reference material ：

• computer network ( The first 7 edition )
• Unix Network Programming Volume 1