❶ linux编程中，一下哪个tcp的套接字选项与nagle算法的开启和关闭有关
从函数调用上来分析（msdn)：一旦完成了套接字的连接，应当将套接字关闭，并且释放其套接字句柄所占用的所有资源。真正释放一个已经打开的套接字句柄的资源直接调用closesocket即可，但要明白closesocket的调用可能会带来负面影响，具体的影响和...
❷ nagle算法和滑动窗口冲突吗
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。
❸ ns3支持哪些TCP算法
当有一个TCP数据段不足MSS，比如要发送700Byte数据，MSS为1460Byte的情况。nagle算法会延迟这个数据段的发送，等待，直到有足够的数据填充成一个完整数据段。也许有人会问，这有什么影响呢？没有太大的影响，总体上来说，这种措施能节省不必要的资源消耗。但是要发送的总体数据很小时，这种措施就是拖后腿了。。
❹ Nagle算法的算法
TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。Nagle算法的规则（可参考tcp_output.c文件里tcp_nagle_check函数注释）：
（1）如果包长度达到MSS，则允许发送；
（2）如果该包含有FIN，则允许发送；
（3）设置了TCP_NODELAY选项，则允许发送；
（4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
（5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。
Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。Nagle算法完全由TCP协议的ACK机制决定，这会带来一些问题，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。
Nagle算法是silly window syndrome(SWS)预防算法的一个半集。SWS算法预防发送少量的数据，Nagle算法是其在发送方的实现，而接收方要做的是不要通告缓冲空间的很小增长，不通知小窗口，除非缓冲区空间有显著的增长。这里显著的增长定义为完全大小的段（MSS）或增长到大于最大窗口的一半。注意：BSD的实现是允许在空闲链接上发送大的写操作剩下的最后的小段，也就是说，当超过1个MSS数据发送时，内核先依次发送完n个MSS的数据包，然后再发送尾部的小数据包，其间不再延时等待。（假设网络不阻塞且接收窗口足够大）
举个例子，比如之前的blog中的实验，一开始client端调用socket的write操作将一个int型数据（称为A块）写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘
’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：
这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'
'（B块）总是在A块之后40ms才发出。当然，TCP确认延迟40ms并不是一直不变的，TCP连接的延迟确认时间一般初始化为最小值40ms，随后根据连接的重传超时时间（RTO）、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置TCP_QUICKACK选项来取消确认延迟。2. TCP_NODELAY 选项
默认情况下，发送数据采用Nagle 算法。这样虽然提高了网络吞吐量，但是实时性却降低了，在一些交互性很强的应用程序来说是不允许的，使用TCP_NODELAY选项可以禁止Nagle 算法。
此时，应用程序向内核递交的每个数据包都会立即发送出去。需要注意的是，虽然禁止了Nagle 算法，但网络的传输仍然受到TCP确认延迟机制的影响。3. TCP_CORK 选项
所谓的CORK就是塞子的意思，形象地理解就是用CORK将连接塞住，使得数据先不发出去，等到拔去塞子后再发出去。设置该选项后，内核会尽力把小数据包拼接成一个大的数据包（一个MTU）再发送出去，当然若一定时间后（一般为200ms，该值尚待确认），内核仍然没有组合成一个MTU时也必须发送现有的数据（不可能让数据一直等待吧）。然而，TCP_CORK的实现可能并不像你想象的那么完美，CORK并不会将连接完全塞住。内核其实并不知道应用层到底什么时候会发送第二批数据用于和第一批数据拼接以达到MTU的大小，因此内核会给出一个时间限制，在该时间内没有拼接成一个大包（努力接近MTU）的话，内核就会无条件发送。也就是说若应用层程序发送小包数据的间隔不够短时，TCP_CORK就没有一点作用，反而失去了数据的实时性（每个小包数据都会延时一定时间再发送）。4. Nagle算法与CORK算法区别Nagle算法和CORK算法非常类似，但是它们的着眼点不一样，Nagle算法主要避免网络因为太多的小包（协议头的比例非常之大）而拥塞，而CORK算法则是为了提高网络的利用率，使得总体上协议头占用的比例尽可能的小。如此看来这二者在避免发送小包上是一致的，在用户控制的层面上，Nagle算法完全不受用户socket的控制，你只能简单的设置TCP_NODELAY而禁用它，CORK算法同样也是通过设置或者清除TCP_CORK使能或者禁用之，然而Nagle算法关心的是网络拥塞问题，只要所有的ACK回来则发包，而CORK算法却可以关心内容，在前后数据包发送间隔很短的前提下（很重要，否则内核会帮你将分散的包发出），即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。
❺ 求编程领域上一些经典算法同时也是程序员必须掌握的算法
这是我在一个论坛里看到的，你也参考参考吧。C++的虚函数
======================
C++使用虚函数实现了其对象的多态，C++对象的开始四个字节是指向虚函数表的指针，其初始化顺序是先基类后派生类，所以该虚函数表永远指向最后一个派生类，从而实现了相同函数在不同对象中的不同行为，使得对象既有共性，又有其个性。
内存池分配、回收之伙伴算法
=======================
伙伴算法是空闲链表法的一个增强算法，依次建立2^0\2^1\2^2\2^3...2^n大小的 内存块空闲链表，利用相邻内存块的伙伴性质，很容易将互为伙伴的内存块进行合并移到相应的空闲链表或将一块内存拆分成两块伙伴内存，一块分配出去，另一块挂入相应空闲链表，使得内存的分配和回收变得高效。
AVL树
=======================
AVL树是一个平衡二叉树，其中序遍历是从小到大排序的，该结构插入节点和检索非常高效，被广泛应用
快速排序
=======================
通过一趟排序将要排序的数据分割成独立的两部分，其中一部分的所有数据都比另外一部分的所有数据都要小，然后再按此方法对这两部分数据分别进行快速排序，整个排序过程可以递归进行，以此达到整个数据变成有序序列。效率非常高
密码学之非对称加密协议（公钥、私钥加密协议）
======================
非对称加密算法需要两个密钥，用其中一个加密产生的密文，只能通过另外一个密钥解密，密钥持有者A可以将其中一个公开，称为公用密钥，另外一个秘密保存称为私钥，这样当某人B想给A传一封秘信时，只要将密信使用A的公钥加密后，就可以放心使用各种信道将迷信传给A了，因为该密信只有A可以解密，第三者截取因为无法解密而毫无意义。
该算法很好地解决了密钥的安全传递的问题，因为公钥和加密算法都是公开的，私钥不需要传输。
密码学之数字签名协议（身份鉴别、防抵赖）
======================
数字签名也是建立在非对称加密基础之上的，如果A君用它的私钥将文件加密后在发布，A君就无法抵赖该文件是其发布的，因为其他人能通过A君的公钥将文件解密就说明，如果算法可靠，该文件一定是A君用其私钥加密的。
由于非对称加密算法的加密和解密很慢，现在的数字签名并非是将其要发布的信息用其私钥加密，而是先用一个单项散列算法如（MD5）产生一个该信息的比较短的指纹（hash值），对其指纹用其私钥加密后和信息一并发布，同样达到了防抵赖的作用。
无回溯字符串模式匹配-kmp算法
======================
他是根据子串的特征，当匹配失败时，不需要回溯，而是直接将字串向后滑动若干个字节，继续匹配，极大提高了匹配速度。该算法被广泛使用。详细请参考数据结构教程。
最小路径选路-迪杰斯特拉算法、弗洛伊德算法
======================
学习数据结构的时候，印象最深的就要算kmp算法和最小路径算法了，因为理解他们比较费脑子，我是不可能发明这些算法了，发明他们的都是天才，呵呵。
使用最短路径的算法曾经帮人写过一个小东西，还是很有效的，记得是使用的弗洛伊德算法的一个变种，要详细了解的朋友可以查找相关资料，想将他们使用在你的项目中，代码直接从教科书上抄就可以了，不需要理解。
tcp协议之-nagle算法
======================
tcp、ip中令人叫绝的想法很多，印象最深的要算nagle算法了。
tcp出于效率和流量控制的考虑，发送端的数据不是产生多少就马上发送多少，一般是等到数据集聚到发送缓冲区长度的一半或者数据达到最大tcp数据包数据部分长度（好像是65515）才启动发送，而且还要看接受端可用缓冲区的大小，如果接受端产生一个回应报文通知发送端没有接受空间了，发送端哪怕缓冲区已经满了，也不会启动发送，直到接受端通告发送端其已经有了接受数据的空间了。
这样就有一个问题，假如发送端就是要发送一个小报文（比如10个字节），然后等待对方的回应。按照上面的方案，tcp会一直等数据收集到一定量才发送，于是矛盾就产生了。应用层不再发数据，tcp等不到足够的数据不会将10个字的数据发送到网卡，接收端应用层收不到数据就不会回应发送端。
你也可能说，可以让修改发送端发送条件，不一定要等到足够的数据再发送，为了效率考虑，可以考虑延时一定的时间，比如说1秒，如果上层还没有数据到来，就将发送缓冲中的数据发出去。当然这样也是可行的，尽管应用端白白等了1秒钟啥也没干，呵呵。
其实nagle算法很好解决了该问题，它的做发是链接建立后的第一次发送不用等待，直接将数据组装成tcp报文发送出去，以后要么等到数据量足够多、要么是等到接受方的确认报文，算法及其简单，而且很好解决了上面的矛盾。
socket之io模型设计
======================
windows下socket有两种工作方式：
1）同步方式
2）异步方式
同步socket又有两种工作模式：
1）阻塞模式
2）非阻塞模式
阻塞模式是最简单的工作模式，以tcp的发送数据为例，如果发送缓冲区没有空间，send调用就不会返回，一直要等到能够发出一点数据为止，哪怕是一个字节，但是send返回并不表示我要发送的数据已经全部提交给了tcp，所以send返回时要检查这次发送的数量，调整发送缓冲指针，继续发送，直到所有数据都提交给了系统。
由于其阻塞的特性，会阻塞发送线程，所以单线程的程序是不适合使用阻塞模式通信的，一般使用一个连接一个线程的方法，但是这种方式对于要维护多个连接的程序，是个不好的选择，线程越多，开销越大。
同步非阻塞模式的socket不会阻塞通信线程，如果发送缓冲区满，send调用也是立刻返回，接受缓冲区空，recv也不会阻塞，所以通信线程要反复调用send或recv尝试发送或接收数据，对cpu是很大的浪费。
针对非阻塞的尴尬，接口开发人员发明了三种io模型来解决该问题：
1）选择模型（select）
2）异步选择模型（AsyncSelect）
3）事件选择模型（EventSeselect）
其思想是根据io类型，预先查看1个或n个socket是否能读、写等。
其select本身来说，select是阻塞的，可以同时监视多个socket，只要所监视的其中一个socket可以读、写，secect调用才返回
异步选择模型其select是异步的（异步是不会阻塞的），是将监视任务委托给系统，系统在socket可读、写时通过消息通知应用程序。有一点需要说明，假如应用程序已经有很多数据需要发送，当收到可写通知时，一定要尽量多地发送数据，直到发送失败，lasterror提示“将要阻塞”，将来才可能有新的可写通知到来，否则永远也不会有。
事件选择模型也是将监视socket状态的工作委托给系统，系统在适当的时候通过事件通知应用程序socket可以的操作。
除了同步工作方式外，还有一种叫异步工作方式
异步工作方式是不会阻塞的，因为是将io操作本身委托给系统，系统在io操作完成后通过回调例程或事件或完成包通知应用程序
异步工作方式有两种io模型和其对应，其实这两种模型是window是异步io的实现：
1）重叠模型
2）完成端口
重叠模型通过事件或回调例程通知应用程序io已经完成
完成端口模型比较复杂，完成端口本身其实是一个io完成包队列。
应用程序一般创建若干个线程用来监视完成端口，这些线程试图从完成端口移除一个完成包，如果有，移除成功，应用程序处理该完成包，否则应用程序监视完成端口的线程被阻塞。
select模型是从UNIX上的Berkeley Software Distribution(BSD)版本的套接字就实现了的，其它四种io模型windows发明的，在windows中完成端口和异步选择模型是使用比较广泛的，一般分别用于服务端和客户端开发。
这五种io模型设计还是比较巧妙的：三种选择模型很好解决了“同步非阻塞”模式编程的不足；重叠模型和完成端口是windows异步io的经典实现，不局限于网络io，对文件io同样适用。
说点题外话，socket的send完成仅仅是将数据（可能是部分）提交给系统，而不是已经发送到了网卡上，更不是已经发送到了接收端。所以要知道你的数据已经发送到了对方的应用层的唯一方法是，让对方给你发送一个应对包。
发送数据要注意，对应tcp，要防止发送和接收的乱序，对于发送，一般应该为每一个链接建立一个发送队列，采用类似nagle的算法启动数据发送。
一次发送可能是你提交数据的一部分，一定要当心，否则出问题没处找去。
❻ 设置tcp哪个socket参数会影响nagle
Nagle算法是避免发送大量的小包来提高网络利用。Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小包。 所谓“小包“，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
Nagle算法的规则（可参考tcp_output.c文件里tcp_nagle_check函数注释）：
（1）如果包长度达到MSS，则允许发送；
（2）如果该包含有FIN，则允许发送；
（3）设置了TCP_NODELAY选项，则允许发送；
（4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
（5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。
影响tcp Nagle算法参数有TCP_NODELAY和TCP_CORK。
接收端的延迟ACK对Nagle算法也有一定的影响。
❼ 设置tcp哪个socket参数 nagle算法
UDP和TCP编程步骤也有些不同，如下：TCP编程的服务器端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();*可选3、绑定IP地址、端口等信息到socket上，用函数bind();4、开启监听，用函数listen()；5、接收客户端上来的连接，用函数accept()；6、收发数据，用函数send()和recv()，或者read()和write();7、关闭网络连接；8、关闭监听；TCP编程的客户端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();*可选3、绑定IP地址、端口等信息到socket上，用函数bind();*可选4、设置要连接的对方的IP地址和端口等属性；5、连接服务器，用函数connect()；6、收发数据，用函数send()和recv()，或者read()和write();7、关闭网络连接；与之对应的UDP编程步骤要简单许多，分别如下：UDP编程的服务器端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();*可选3、绑定IP地址、端口等信息到socket上，用函数bind();4、循环接收数据，用函数recvfrom();5、关闭网络连接；UDP编程的客户端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();*可选3、绑定IP地址、端口等信息到socket上，用函数bind();*可选4、设置对方的IP地址和端口等属性;5、发送数据，用函数sendto();6、关闭网络连接；
❽ 设置tcp的哪个socket参数会影响了nagle算法
TCP_NODELAY
❾ 有socket编程经验或懂得网卡硬件的朋友请进！！！
C语言里的Sleep函数可以实现DoEvent()的功能
Remarks
A thread can relinquish the remainder of its time slice by calling this function with a sleep time of zero milliseconds.
一个线程能够呼叫这个函数时把参数设置成为0实现放弃所拥有的剩余时间片。