Objective
Using the centos6.5 system's own netstat,grep,watch and other commands to analyze the network connection status requires a deep understanding of the concept of TCP finite state machine.
At the same time, this is in addition to using powerful professional third-party protocol analyzers, such as Wireshark, the most effective way.
One of the purposes of writing a blog is to tell you that you do not use third-party tools such as Wireshark, you can also do a certain granularity of network connectivity, state analysis, debugging and so on.
The commands used are summarized as follows:
Watch-n 1-d ' Netstat-antupeo | grep--color 8.8.8.8 '
Watch-n 1-d ' Netstat-antupeo | grep--color syn_sent '
Watch-n 1-d ' Netstat-antupeo | grep--color time_wait '
Watch-n 1-d ' Netstat-antupeo | grep--color established ' watch-n 1-d ' Netstat-antupeo | grep--color fin_wait1 '
650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/39/54/wKioL1O41PPxaE5FAA0KapATTC0505.jpg "title=" Using parameters of netstat command to analyze TCP connection and shutdown process 1.jpg "alt=" wkiol1o41ppxae5faa0kapattc0505.jpg "/>650" this.width=650; "src="/HTTP/ S3.51cto.com/wyfs02/m02/39/54/wkiom1o41dhwhl2oaa7mictygmg080.jpg "title=" skillfully using parameters of netstat command to analyze TCP connection and shutdown process 2.jpg "alt=" Wkiom1o41dhwhl2oaa7mictygmg080.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/39/54/wKioL1O41diQjgQxAA_NDwzNSMY576.jpg "style=" float: none; "title=" skillfully uses the parameters of the netstat command to analyze the TCP connection and shutdown process 3.jpg "alt=" Wkiol1o41diqjgqxaa_ndwznsmy576.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/39/54/wKioL1O41ffhPJl1ABM4BTS9tjY420.jpg "style=" float: none; "title=" skillfully uses the parameters of the netstat command to analyze the TCP connection and shutdown process 4.jpg "alt=" Wkiol1o41ffhpjl1abm4bts9tjy420.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/39/54/wKiom1O41jKR81NdABPx6_teK08657.jpg "style=" float: none; "title=" skillfully uses the parameters of the netstat command to analyze the TCP connection and shutdown process 6.jpg "alt=" Wkiom1o41jkr81ndabpx6_tek08657.jpg "/>
650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/39/54/wKioL1O41gqDj1F9AA6voLQiTV4987.jpg "style=" float: none; "title=" skillfully uses the parameters of the netstat command to analyze the TCP connection and shutdown process 7.jpg "alt=" Wkiol1o41gqdj1f9aa6volqitv4987.jpg "/>
Additional notes: About TIME_WAIT
As we mentioned earlier, it is not a problem to start a time_wait timer for up to 60 seconds on the client, but if it is on a high-concurrent access, high-load server, this can cause noticeable performance problems.
The reason is that on the server side, each UNIX domain socket in the TCP time_wait state (assuming that the server-side operating system is Linux, a variant of Unix) consumes a TCP port, which has a very limited number of ports available.
Typically there are only 60,000 or more ports that end from 1024 to 65535.
Now assume that the first TCP connection belonging to 60,000 different source IPs arrives at the server, and the Web server returns the HTTP response with the Connection:close response header in the shortest time and starts the 60-second time_wait timer, which means that in 60 seconds, 60,000 more ports will not be Reuse. Assuming that the second batch of tens of thousands of different source IP TCP connections arrives during this time, it is clear that the server will not be able to allocate any available port resources to handle these connections, and thus have to wait 60 seconds to free up the occupied port resources.
We can assume that the availability and concurrency capabilities of this server are low during this time period.
Do not assume that the described scenario will not appear. In fact, for some large internet companies to maintain the portal, at some point in time to encounter a continuous tens of thousands of, or even hundreds of thousands of peak of concurrent access traffic. And there is no case for a distributed denial of service (DDOS) attack.
Perhaps because of this, the Linux kernel provides several parameters, configuration items, to tune the performance of the TCP/IP protocol stack, including:
Limit the total number of ports in the TIME_WAIT state once you have exceeded the immediate zeroing threshold
Time_wait status port reuse, fast recovery
Increase the upper bound of an open socket descriptor (one of the file descriptors)
TCP SYN Cookie Technology for mitigating DDoS attacks to some extent
So, in these sense, Linux is indeed more appropriate than Windows for the underlying server operating system of a large site.
This article is from the "4681835" blog, be sure to keep this source http://4691835.blog.51cto.com/4681835/1434989