分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由应用服务器发送给客户端应用（ 通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。HTTP 1.1引入分块传输编码提供了以下几点好处：HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久连接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。[动态内容，content-length无法预知]分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字 ...继续阅读 (125)

MySQL有大量可以修改的参数－－但不应该随便去修改。通常只需要把基本的项配置正确（大部分情况下只有很少一些参数是真正重要的），应该将更多的时间花在schema的优化、索引，以及查询设计上。在正确地配置了MySQL的基本配置项之后，再花力气去修改其它配置项的收益通常就比较小了。1.创建MySQL配置文件建议不要使用操作系统的安装包自带的配置文件，最好从头开始创建一个配置文件。（首先要确定MySQL使用了哪个配置文件！）2.InnoDB缓冲池（Buffer Pool）有一个流行的经验法则说，应该把缓冲池大小设置为服务器内存的约75~80%，但并不总是正确的。有一个更好的办法来设置缓冲池大小，大致如下：1、从服务器内存总量开始2、减去操作系统的内存占用3、减去一些MySQL自身需要的内存4、减去足够让操作系统缓存InnoDB日志文件的内存，至少是足够缓存最近经常访问的部分。5、减去其他配置的MySQL缓冲和缓存需要的内存，例如查询缓存，MYISAM键缓存6、除以105%，把结果向下取一个合理的数值。如果大部分都是InnoDB表，InnoDB缓冲池或许比其他任何东西更需要内存。InnoDB缓冲池并不仅仅缓存索引：它还缓存行的数据、自适应哈希索引、插入缓存（Insert buffer）、锁、以及其他内部数据结构。InnoDB还使用缓冲池来帮助延迟写入，这样就能合并多个写入操作，然后一起顺序 ...继续阅读 (44)

对于高性能数据库操作，只靠设计最优的库表结构、建立最好的索引是不够的，还需要合理的设计查询。如果查询写得很糟糕，即使库表结构再合理、索引再合适，也无法实现高性能。查询优化、索引优化、库表结构优化需要齐头并进，一个不落。6.1 为什么查询速度会慢通常来说，查询的生命周期大致可以按照顺序来看：从客户端>>服务器>>在服务器上进行解析>>生成执行计划>>执行>>返回结果给客户端。其中执行可以认为是整个生命周期中最重要的阶段，这其中包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序、分组等。了解查询的生命周期、清楚查询的时间消耗情况对于优化查询有很大的意义。6.2 优化数据访问查询性能低下的最基本的原因是访问的数据太多。大部分性能低下的查询都可以通过减少访问的数据量的方式进行优化。1.确认应用程序是否在检索大量超过需要的数据。这通常意味着访问了太多的行，但有时候也可能是访问了太多的列。2.确认MySQL服务器层是否在分析大量超过需要的数据行。6.2.1 是否向数据库请求了不需要的数据请求多余的数据会给MySQL服务器带来额外的负担，并增加网络开销，另外也会消耗应用服务器的CPU内存和资源。这里有一些典型案例：1、查询不需要的记录：例如在新闻网站中取出100条记录，但是只是在页面上显示10条。实际上MySQL会查询出全部的结果乌鸦，客户端的应用程序会接收全部的结果集数据，然 ...继续阅读 (31)

一、MySQL逻辑架构MySQL最重要的、最与众不同的特性是它的存储引擎架构，这种构架的设计将查询处理及其它系统任务和数据的存储/提取相分离。第一层，服务层，最上层的服务并不是MySQL独有的，大多数基于网络的客户端/服务端的工具或者服务都有类似的架构。主要为请求做连接处理，授权认证，安全等。第二层，核心层，大多数MySQL的核心服务功能都在这一层，包括查询解析，分析，优化，缓存，以及所有的内置函数（例如日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程，触发器，视图等。第三层，存储引擎，存储引擎负责MySQL中数据的存储和提取。服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎不会去解析SQL，不同存储引擎之间也不会相互通信，而只是简单地响应上层服务的请求。连接管理与安全性(第一层 服务层)> 连接流程Δ 每个连接的查询都在一个进程中的线程完成。Δ 服务器负责缓存线程，所以服务层不需要为每个新建的连接创建或者销毁线程（可以使用线程池）。> 认证流程1、当客户端（应用）连接到MySQL服务器时，服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。如果使用了安全套接字的方式连接，还可以使用X.509证书认证。2、一旦客户端连接成功，服务器会继续验证该客户是否具有执行某个查询的权限（例如对 ...继续阅读 (35)

1、MySQL查询缓存很多数据库产品都能够缓存查询的执行计划，对于相同类型的SQL就可以跳过SQL解析和执行计划生成阶段。MySQL还有另一种不同的缓存类型：缓存完整的SELECT查询结果，也就是“查询缓存”。查询缓存系统会跟踪查询中涉及的每个表，如果这些表发生变化，那么和这个表相关的所有的缓存数据都将失效。查询缓存对应用程序是完全透明的。应用程序无须关心MySQL是通过查询缓存返回的结果还是实际执行返回的结果。另外，随着现在的通用服务器越来越强大，查询缓存可能是一个影响服务器扩展性的因素。它可能成为整个服务器的资源竞争单点，在多核服务器上还可能导致服务器僵死。1.1查询缓存的工作机制Mysql 判断是否命中缓存的办法很简单，首先会将要缓存的结果放在引用表中，然后使用查询语句，数据库名称，客户端协议的版本等因素算出一个hash值，这个hash值与引用表中的结果相关联。如果在执行查询时，根据一些相关的条件算出的hash值能与引用表中的数据相关联，则表示查询命中。通过have_query_cache服务器系统变量指示查询缓存是否可用：mysql>SHOW VARIABLES LIKE 'have_query_cache';+------------------+-------+| Variable_name | Value |+------------------+------- ...继续阅读 (25)

1.慢查询当一个资源变得效率低下的时候，应该了解一下为什么会这样。有如下可能原因：1.资源被过度使用，余量已经不足以正常工作。2.资源没有被正确配置3.资源已经损坏或者失灵因为慢查询，太多查询的时间过长而导致堆积在逻辑上。慢查询到底是原因还是结果？在深入调查前是无法知晓的。记住，在正常的时候这个查询也是正常运行的。一个查询需要filesort和创建临时表并不一定意味着就是有问题的。尽管消除filesort和临时表通常来说是“最佳实践”。2.MySQL数据类型更小的通常更好：一般情况下，应该尽量使用可以正确存储数据的最小数据类型。更小的数据类型通常更快，因为它们占用更少的磁盘、内存和cpu缓存，并且处理时需要的cpu周期也更少。简单就好：简单数据类型的操作通常需要更少的cpu周期，例如整型比字符操作代价更低，因为字符集和校对规则（排序规则）使字符比较比整型比较更复杂，使用整型存储IP地址。尽量避免NULL：通常情况下最好制定列为NOT NULL，除非真的需要存储NULL值。如果查询中包含可为NULL的列，对mysql来说更难优化，因为可为NULL的列使得索引、索引统计和值比较都更复杂。很多MySQL的数据类型可以存储相同类型的数据，只是存储的长度和范围不一样、允许的精度不同，或者需要的物理空间（磁盘和内存空间）不同。别名MYSQL为了兼容性支持很多别名，例如integer、bool、 ...继续阅读 (51)

1.AUTOCOMMITMysql采用默认自动提交，可以通过如下命令查看和修改：mysql> SHOW VARIABLES LIKE 'AUTOCOMMIT';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+1 row in set (0.00 sec)mysql> SET AUTOCOMMIT = 1;2.隐式锁显式锁InnoDB在开启事务时，获取隐式锁，在事务提交或者回滚时释放锁，InnoDB根据隔离级别在需要的时候自动加锁。但InnoDB也支持显式锁：SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODE这是在服务器层实现的，和存储引擎无关。本书建议除了禁用了AUTOCOMMIT，可以使用LOCK_TABLES之外，其他任何时候都不要显示地执行LOCK TABLES，不管使用的是什么存储引擎。3.多版本并发控制（Multiversion Concurrency Controll MVCC）第一点：MVCC并不是MySql独有的，Oracle，PostgreSQL等都在使用。MVCC并没有简单地使用行锁，而是使用“行级别锁”（row-level ...继续阅读 (162)

1.锁为什么需要锁？因为数据库要解决并发控制问题。在同一时刻，可能会有多个客户端对表中同一行记录进行操作，比如有的在读取该行数据，其他的尝试去删除它。为了保证数据的一致性，数据库就要对这种并发操作进行控制，因此就有了锁的概念。1.1锁的分类从对数据操作的类型（读\写）分读锁（共享锁）：针对同一块数据，多个读操作可以同时进行而不会互相影响。写锁（排他锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。大多数时候，MySQL锁的内部管理都是透明的。1.2锁粒度（Lock granularity）为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取，检查，释放锁等动作），因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度（Lock granularity）”的概念。一种提高共享资源并发发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。但是，加锁也需要消耗资源。锁的各种操作，包括获得锁、检查锁和是否已经解除、释放锁等，都会增加系统的开销。所谓锁策略，就是在锁的开销和数据的安全性之间寻求平衡。表锁 ...继续阅读 (27)

1.RST标识位RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。发送RST包关闭连接时，不必等缓冲区的包都发出去（FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。TCP处理程序会在自己认为的异常时刻发送RST包。2个例子：1）A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。2）A和B已经正常建立连接，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，A网断了，A通过若干原因放弃了这个连接（例如进程重启）。网络恢复之后，B又开始或重发数据包，A不知道这连接哪来的，就发了个RST包强制把连接关闭，B收到后会出现connect reset by peer错误。2.RST复位报文段TCP在下列三种情况下产生RST复位报文段。1.到不存在的端口的连接请求产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息；而TCP则使用复位。2.异常终止一个连接终止一个连接的正常方式是一方发送FIN，这也称为有序释放，因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是FIN来中途释放一个连接，这也称为异常释放。异常终止一个连接对 ...继续阅读 (33)

在查看TCP标识位SYN时，顺便关注了一下SYN Flood，从网上查阅一些资料加以整理，SYN洪水攻击利用TCP三次握手。1.SYN洪水介绍当一个系统（客户端C）尝试和一个提供了服务的系统（服务器S）建立TCP连接，客户端C和服务端S会交换一系列报文。正常的3次握手连接：首先是C发送一个SYN报文给服务端S，然后这个服务端发送一个SYN-ACK包以回应C，接着，C就返回一个ACK包来实现一次完整的TCP连接。就这样，C到服务端的连接就建立了，这时C和服务端就可以互相交换数据了。SYN洪水：在S返回一个确认的SYN-ACK包的时候，S可能由于各种原因不会接到C回应的ACK包。这个也就是所谓的半开放连接，S需要 耗费一定的数量的系统内存来等待这个未决的连接，虽然这个数量是受限，但是恶意者可以通过创建很多的半开放式连接来发动SYN洪水攻击 。攻击者可以通过IP欺骗发送SYN包给受害者系统，这个看起来是合法的，但事实上所谓的C根本不会进行ACK回应服务端S的SYN-ACK报文，这意味着受害者将永远不会接到ACK报文。 而此时，半开放连接将最终耗用受害者所有的系统资源（即使等待ACK包有超时限制），受害者将不能再接收任何其他的请求。2.SYN cookieSYN cookie用一个cookie来响应TCP SYN请求的TCP实现，在正常的TCP实现中，当S接收到一个SYN数据包，他返回 一 ...继续阅读 (39)

1.服务器异常如果服务器出了异常，十之八九都是以下两种情况：1.服务器保持了大量TIME_WAIT状态2.服务器保持了大量CLOSE_WAIT状态因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，一旦达到句柄数上限，新的请求就无法被处理了，接着应用程序可能返回大量Too Many Open Files异常。2.Close_Wait引发的问题Close_Wait会占用一个连接，网络可用连接小。数量过多，可能会引起网络性能下降，并占用系统非换页内存。 尤其是在有连接池的情况下(比如HttpRequest)会耗尽连接池的网络连接数，导致无法建立网络连接。3.解决方法下面来讨论下这两种情况的处理方法，优化系统内核参数解决TIME_WAIT可能很容易，可以通过修改/etc/sysctl.conf文件解决；但是应对CLOSE_WAIT的情况还是需要从程序本身出发。因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出FIN信号，一般原因都是TCP连接没有调用关闭方法。换句话说，就是在 ...继续阅读 (31)

1.TIME_WAIT状态存在的两个理由：1）让4次握手关闭流程更加可靠；4次握手的最后一个ACK是是由主动关闭方发送出去的，若这个ACK丢失，被动关闭方会再次发一个FIN过来。若主动关闭方能够保持一个2MSL的TIME_WAIT状态，则有更大的机会让丢失的ACK被再次发送出去。如果主动关闭端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么当主动端ACK丢失，被动方将重发最终的FIN，而主动端将响应RST，被动端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态 。2）允许老的重复分节在网络中消逝，防止lost duplicate对后续新建正常链接的传输造成破坏。lost duplicate在实际的网络中非常常见，经常是由于路由器产生故障，路径无法收敛，导致一个packet在路由器A，B，C之间做类似死循环的跳转。IP头部有个TTL，限制了一个包在网络中的最大跳数，因此这个包有两种命运，要么最后TTL变为0，在网络中消失；要么TTL在变为0之前路由器路径收敛，它凭借剩余的TTL跳数终于到达目的地。但非常可惜的是TCP通过超时重传机制在早些时候发送了一个跟它一模一样的包 ...继续阅读 (39)

现实中可能存在这么一种空闲TCP连接：没有任何数据流通过。也就是说，如果TCP连接的双方都没有向对方发送数据，则在两个TCP模块之间不交换任何信息，这意味着我们可以启动一个客户与服务器建立连接，然后长时间不使用，而连接依然保持。中间的路由器可以崩溃和重启，电话线可以被挂断再连接，但只要两端的主机没有被重启，则连接依然保持建立。然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动，许多实现提供的保活定时器可以提供这种能力。保活并不是TCP规范中的一部分。保活定时器工作原理：如果一个给定的连接在2小时内没有任何动作，那么服务器就向客户发送一个探查报文段。客户主机必须处于以下4个状态之一：(1)客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方的正常工作的，服务器在2小时内将保活定时器复位。(2)客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应，服务器将不能收到对探查的响应，并在75秒后超时，总共发送10个探查，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。(3)客户主机崩溃并已经重新启动。这是服务器将收到一个对其保活探查的响应，但这个响应是一个RST复位，使得服务器终止这个连接。(4)客户主机正常运行，但是从服务器不可达。这与状态2相同，因为TCP不能够区分状态4与2之 ...继续阅读 (33)

TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对于实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传频率。TCP管理4种不同的定时器：重传定时器：当希望收到另一端的确认时使用。坚持定时器：使窗口信息保持不断流动，即使另一端关闭了其接收窗口。保活定时器：检测一个空闲连接的另一端何时崩溃或重启。2MSL定时器：测量一个连接处于TIME_WATI状态的时间。指数退避：书中检查连续重传之间不同的时间差，它们取整后分别是1、3、6、12、24、48和多个64秒，其中第一次发送后设置的超时时间设置为1.5秒。（2的N次方*1.5秒）1.往返时间测量RTT(往返时间)：指发送端发送TCP报文段开始到接收到对方的确定所使用的时间。TCP超时与重传中最重要的部分就是对一个给定连接的往返时间的测试。由于路由器和网络流量均会变化，因此我们认为这个时间可能经常会发生变化，TCP应该跟踪这些变化并相应地改变其超时时间。RTO(超时重传时间)：发送端发送TCP报文段后，在RTO时间内没有收到对方确定，即重传该报文段。最早的TCP曾经用了一个非常简单的公式来估计当前网络的状况，如下：R<-aR+(1-a)MRTP=Rb其中a是一个经验系数为0 ...继续阅读 (32)

TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为0会发生什么情况呢？这将有效阻止发送方传送数据，直到窗口变为非0为止。ACK的传输并不可靠，也就是说，TCP不对ACK报文段进行确认，TCP只确认那些包含有数据的ACK报文段。1.坚持定时器假设一个场景：如果一个确认丢失了，则双方就有可能因为等待对方而使连接终止，接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器（persist timer）来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查（window probe）。计算坚持定时器时使用了普通的TCP指针退避，窗口探查报文包含一个字节的数据。坚持状态与21章介绍的重传超时之间一个不同的特点就是TCP从不放弃发送窗口探查。这些探查每隔60秒发送一次，这个过程将持续到窗口打开或者应用进程使用的连接被终止。2.糊涂窗口综合症糊涂窗口综合症：接收方可以通告一个小的窗口（而不是一直等到有大的窗口时才通告），而发送方可以通过这个小窗口发送少量的数据（而不是等待其它的数据以便发送一个大的报文段），即，少量的数据通过连接交换，而不是满长度的报文段，TCP的传输效率可想而知。如何避免“糊涂窗口综合症”：接收方：接收方 ...继续阅读 (58)

TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须在双方之间建立一条连接。这种两端间连接的建立与无连接协议UDP不同，UDP向另一端发送数据报时，无需任何预告的握手。1.建立连接的协议（3次握手）1）请求端发送一个SYN段指明客户端打算连接的服务器端口，以及初始序列号。2）服务器发回包含服务器的初始序号的SYN报文段作为应答。同时将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。3）客户端将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认ISN随时间而变化，因此每个连接都将具有不同的ISN。RFC793指出ISN可以看作是一个32比特的计数器，每4ms加1。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作出错误的解释。2.连接终止协议建立一个连接需要3次握手，为什么终止一个连接需要4次握手？这由TCP的半关闭造成的。既然一个TCP连接是全双工（数据在两个方向能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送后就能发送一个FIN来终止这个方向数据。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。收到FIN包意味着在这一方向上没有数据流动（接收）。一个TCP连接在收到一个FIN后仍能发送数据。3.最大报文段长度最大报文段长 ...继续阅读 (27)

目前建立在TCP协议上的网络协议特别多，有telnet，ssh，有ftp，有http等等。这些协议又可以根据数据吞吐量来大致分成两大类：(1)交互数据类型，例如telnet，ssh，这种类型的协议在大多数情况下只是做小流量的数据交换，比如说按一下键盘，回显一些文字等等。(2)数据成块类型，例如ftp，这种类型的协议要求TCP能尽量的运载数据，把数据的吞吐量做到最大，并尽可能的提高效率。针对这两种情况，TCP给出了两种不同的策略来进行数据传输。本章介绍TCP所使用的被称为窗口协议的另一种形式的流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。1.隔一个报文段确认策略TCP处理一个接收的报文将产生一个经受时延的确定，此ACK并不立即返回，这时分两种情况（隔一个报文或者定时器溢出）：(1)TCP处理下一个报文，然后返回一个ACK确定2个报文段(可以想象成捎带ACK)。(2)定时器溢出，返回ACK。如果溢出时，TCP接收缓冲区中还有数据没有被应用层读取完，那么返回报文段的窗口值将为初始窗口值减去缓冲区中的值。2.滑动窗口协议窗口移动:(1)窗口左边沿向右边沿靠近为窗口合拢。(2)窗口右边沿向右边移动为窗口张开。(3)窗口右边沿向左边移动为窗口收缩。RFC强烈建议不要使用这种方式如果左边沿到达右边沿 ...继续阅读 (25)

在TCP进行数据传输时，可以分为成块数据流和交互数据流两种，如果按字节计算，成块数据与交互数据的比例约为90%和10%，TCP需要同时处理这两类数据，且处理的算法不同。书籍本章中以Rlogin应用为例观察交互数据的传输过程。提示经受时延的确认是如何工作以及Nagle算法怎样减少了通过广域网络传输的小分组的数目。交互式输入上图为没有优化的字符输入回显的数据传输过程，一共需要四个报文段。经受时延的确认上图第二，三个报文段可以合并---按键确认和按键回显一起发送。这种技术叫做经受时延的确认。通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时这种现象为数据捎带的ACK）。绝大数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送。ACK延时等待时间不大于TCP定时器的原因:假如TCP使用200ms的定时器，该定时器将相对于内核引导的200ms固定时间溢出，由于将要确定的数据随机到达，TCP将在下一次内核的200ms定时器溢出时得到通知，所以ACK实际等待的时间为1~200ms中任一刻。Nagle算法Nagle算法要求TCP连接上最多只有一个未被确认的未完成小分组，在该分组确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到达时以一个大的分组发出去。该算法的优点在于它是 ...继续阅读 (39)

1.TCP的服务在一个TCP连接中，仅有两方进行彼此通信。TCP通过下列方式来提供可靠性：1）应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度保持不变。由TCP传递给IP的信息单位称为报文段或段。2）当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段，这将在21章中重传策略中讨论。3）当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通过将推迟几分之一秒，这将在19章中讨论。4）TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据文件在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）5）既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。6）既然IP数据报会发生重发，TCP的接收者必须丢弃重复的数据。7）TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。TCP提供面向连接的，可靠的字节流服务。2.TCP的首部TCP数据被封装 ...继续阅读 (28)