1. 关于select和epoll的本质的技术文章，解析的很透彻
https://cloud.tencent.com/developer/article/1531095
2. ping的本质，从这篇文章里可以了解ICMP协议的用途
https://www.jianshu.com/p/e1795962ad76
如何实现ping的功能
https://blog.csdn.net/hengyunabc/article/details/24897199
3.讲解ICMP协议的文章
https://blog.csdn.net/baidu_37964071/article/details/80514340
4.讲解ARP的文章
https://blog.csdn.net/ever_peng/article/details/80008638
5.讲解NAT的文章
https://blog.csdn.net/qq_34228570/article/details/80203924
6. 讲解IP协议中目的mac地址的获取的文章
https://blog.csdn.net/Perfect11_1/article/details/82017101
7.讲解traceroute原理的文章
https://www.cnblogs.com/lcword/p/9862539.html
8. 关于如何检测socket断开的文章
https://blog.csdn.net/romainxie/article/details/8161932
关于各种异常情况下对端socket断开，本端socket收到的信号的总结，比较详细
https://blog.csdn.net/whatday/article/details/100121412
关于socket读写各种错误的总结
https://blog.csdn.net/gaoshou_zgt/article/details/78363335
9.非阻塞connect的返回值讲解
https://www.iteye.com/blog/lionvp-1177411
10. 关于EAGAIN EWOULDBLOCK EINTR错误的讲解文档
http://blog.sina.com.cn/s/blog_77d329940102wwc4.html
我自己总结的话就是，首先EAGAIN错误和EWOULDBLOCK是同一种错误，这种错误一般发生在设置了非阻塞标志的文件操作上，比如文件、socket等的读写操作，发生这种错误时，标志着这个操作还未就绪，比如写时缓冲区已满、读时数据未就绪，通过EWOULDBLOCK的定义名称也可以看出，如果这个时候文件句柄没有设置非阻塞标志，此时的操作是会阻塞的，但是因为有非阻塞标志，所以要立即返回，所以就返回这种错误来提示调用者此时操作并没有真的发生错误，只是未就绪而已，所以这个时候调用者可以稍后再调用这个函数即可。这个错误在Windows平台上叫做WSAEWOULDBLOCK。另外，这个地方我觉得有个地方要注意下，就是socket的connect函数，这个函数如果在socket设置了非阻塞标志时，它返回的是EINPROGRESS，并不是上面两个。
关于EINTR错误的讲解文档
https://www.xuebuyuan.com/1470645.html
EINTR这个错误的情形，我感觉比上面两个要难理解一些，大体意思就是，在做一些慢系统调用，也就是阻塞调用时，比如socket的读写等（注意这个地方的socket是阻塞模式的），由于有其它信号的产生，导致进程被唤醒，这个时候，调用就会返回这个错误。但是文件的读写就不会这样，这是因为进程在被挂起时，有可唤醒和不可唤醒两种状态，文件读写时，进程处于不可唤醒状态，这时候就算收到了其它的信号，进程也不会被唤醒，所以调用不会返回这个错误。但是socket等的操作，进程处于可被唤醒的状态，这个时候如果有其他信号把进程唤醒了，就会发生这种错误，发生这种错误后，一般也是重新调用下函数来解决。另外我觉得这个地方所谓的进程被唤醒应该有个前提条件，因为cpu调度的基本单位是线程，应该是只有信号唤醒的进程中的线程和正在做系统调用的线程同属一个的时候，才会这样，如果两者都不在一个线程，那这个阻塞调用根本没必要返回，继续阻塞就行了。上面文档里的代码例子中，阻塞的系统调用和设置的信号唤醒都是在主线程，所以才会返回EINTR这个错误。
11. 关于TCP的RESET报文
https://blog.csdn.net/hik_zxw/article/details/50167703
这片文章介绍的比较全面，按照我的理解是，reset报文一般是在tcp被异常关闭后，比如程序崩溃等，被异常关闭的的一方，在收到远端的tcp消息后，会发送一个tcp reset报文给对方，告诉对方，这个tcp连接已经不存在了。发送tcp reset报文应该是操作系统底层自动实现的。
这也就解释了上面第8条中的关于tcp异常断开后，另一端可以收到 104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”的错误提示了。
其实UDP相关的操作也会返回RESET错误，udp和tcp不同，tcp是因为对方主机发送了tcp reset报文，而udp则是因为上一次的发送导致了一个ICMP的unreachable port错误。虽然返回的错误码相同，但是操作系统底层得知错误的机制确是不同的。
12 有关tcp的滑动窗口和拥塞控制的文章
https://www.cnblogs.com/lisuyun/articles/5803352.html
