Last Saturday I gave the talk “Nginx Internals” in Guangzhou. Here are the presentation slides and the video of the talk.
Nginx Internals Video part 1 (in Chinese):
Nginx Internals Video part 2 (in Chinese):
Nginx Internals Video part 3 (in Chinese):
nginx map (click to view large image)
I’m going to give a free talk on nginx’s internals next month (September 19), in Guangzhou, China.
I’ve been reading the source code of nginx for a few days. Digging into this charming code is really a pleasant experience, though at first glance it appeared a little bit difficult to understand. Nginx becomes more and more popular, but unfortunately there is not enough documentation on its architecture and implementation. Now that I have spent a considerable amount of time reading the source code and have gained some knowledge, why not share it with those who want to know things under the hood?
So, if you are interested in this talk and you can be in Guangzhou that day, feel free to join in. Please comment on this post or drop me an email to let me know which parts you are interested in (see the mind map above, draft version though).
There might be a thousand Hamlets in a thousand people’s eyes. Note that I’m not Igor, and the only way I try to understand the nuts and bolts is by reverse engineering it, hence I can’t guarantee you no mistakes or misunderstandings in my talk. And frankly, it is not a trivial topic after all, not only because of the size of nginx’s code base, but also its elaborate design.
The speech will be in Chinese while slides will be in English. Specifics of time and location are coming soon. Stay tuned.
Update:
Time: 14:30-17:30, September 19, 2009
Location: Netease Building Tower E, Guangzhou Information Port #16 Keyun RD. Tianhe District, Guangzhou
Registration: http://blog.laiyonghao.com/2009/09/programming-tech-party/370
Yesterday, I gave a talk entitled “Tips on High Performance Server Programming” to some computer science graduate students at Jinan University. Below are the slides I used for the talk.
I’m surprised by the fact that so many network programmers don’t know TIME_WAIT and CLOSE_WAIT well, particularly those who use Java, C#, Python and etc.
It is true, however, TIME_WAIT and CLOSE_WAIT are the most confusing two among TCP’s 11 states (CLOSED, LISTEN, SYN_SENT, SYN_RECV, ESTABLISHED, CLOSE_WAIT, LAST_ACK, FIN_WAIT1, FIN_WAIT2, CLOSING, and TIME_WAIT), which are displayed by netstat(1).
Before going into detail, let me explain the terms first:
Active Open: An end sends a SYN segment to the other end by calling connect(2). This end is usually called a client.
Passive Open: An end issues a passive open by calling socket(2), bind(2), and listen(2) so that it can accept(2) the clients’ connections. This end is usually called a server.
Active Close: An end performs active close when it calls close(2) first. It results a FIN segment being sent.
Passive Close: The other end receives the FIN segment performs the passive close.
MSL: Maximum Segment Lifetime, the maximum time a segment can live in the network before being discarded.
Now take a look at the TCP state transition diagram.
TCP State Transition Diagram 1
TCP State Transition Diagram 2
In the diagrams above, I denote the active open/close transitions with a green line and the passive open/close transitions with a blue line (Normal transitions are in bold). The end that performs the active close goes through the TIME_WAIT state; while the end performs the passive close enters the CLOSE_WAIT state. Note that either end (the server or the client) can perform the active close!
What’s the TIME_WAIT state for?
1) When the final ACK being sent by the end that performed the active close was lost, the other end would resend a FIN. TCP maintains the information of the connection, hence it would resend the lost ACK rather than respond with an RST (interpreted as error).
2) To allow wandering duplicates to expire in the network, so that the duplicate segments would not corrupt later connections.
The value of TIME_WAIT delay is 2MSL, which is TCP implementation dependent and is generally about 1-4 minutes.
CLOSE_WAIT happens when an end has received a FIN segment from the other end, to wait for the program to close the socket. Long duration of CLOSE_WAIT suggests that there might be a bug in your program. In fact, a TCP connection can stay in the CLOSE_WAIT state forever unless it is explicitly closed. It is the application’s responsibility to close its socket after use, to release the resource of the connection.
Conclusion:
In most cases, there is no need to worry about TIME_WAIT. It is a safety feature of TCP. But you really should take care of CLOSE_WAIT. Also note, if a connection is in CLOSE_WAIT, it would never end up in the TIME_WAIT state, and vice versa. BTW, if you haven’t read Richard Stevens’ Unix Network Programming, go out and buy one. It is a must-have for all network programmers, even if you do Windows programming.
Download the dot files and msc file here:
http://www.zhuzhaoyuan.com/download/tcp/tcp-state1.dot
http://www.zhuzhaoyuan.com/download/tcp/tcp-state2.dot
http://www.zhuzhaoyuan.com/download/tcp/tcp_close.msc
