TCP/IP网络协议

TCP/IP 5层模型和OSI 7层模型

注意到，前者的应用层对应了后者的应用层、表示层和会话层。

常用设备

网络层：路由器、防火墙
数据链路层：网卡、网桥、交换机
物理层：中继器、集线器

TCP/IP协议簇

TCP/IP协议簇包括应用层、传输层、网络层、数据链路层。
其中应用层包括：
HTTP：端口号80
HTTPS：443
文件传输协议(FTP），端口号21
远程登录(Telnet)：提供远程访问其它主机功能，它允许用户登录internet主机,并在这台主机上执行命令，端口号23
SMTP协议，端口号25。SMTP：发送或者中转邮件，pop3：从服务器下载到本地。
域名系统(DNS)，该系统用于在internet中将域名及其公共广播的网络节点转换成IP地址，端口号53
网络管理(SNMP简单网络管理协议)，该协议提供了监控网络设备的方法,以及配置管理,统计信息收集,性能管理及安全管理等，端口号161

网络层包括:
Internet协议(IP)
Internet控制信息协议(ICMP)
地址解析协议(ARP)
反向地址解析协议(RARP)

DNS

DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。DNS就是这样的一位“翻译官”，它的基本工作原理可用下图来表示。

递归查询与迭代查询

递归查询: 简单的理解就是以最终结果查询，就是返回最终的结果给客户机，而客户机在此阶段是处于等待的状态！（就好比，你在家里地位最高，你都是衣来伸手饭来张口的，最什么事情就只要一句话不用自己亲自动手）

迭代查询：简单的理解就是以最佳的结果查询，意思就是如果DNS服务器能解析就直接以最终结果返回给客户机，如果无法解析则就返回上一级DNS服务器的IP给客户机，由客户机完成查询工作直到得到最终结果！（举个例子就是什么事情你去问别人，别人只是告诉你怎么做，你知道后要自己亲自去做）

从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

什么是DNS劫持

DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。

DNS劫持症状：在某些地区的用户在成功连接宽带后，首次打开任何页面都指向ISP提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问Google域名的时候出现了百度的网站。这些都属于DNS劫持。

什么是DNS污染

DNS污染是一种让一般用户由于得到虚假目标主机IP而不能与其通信的方法，是一种DNS缓存投毒攻击（DNS cache poisoning）。
其工作方式是：由于通常的DNS查询没有任何认证机制，而且DNS查询通常基于的UDP是无连接不可靠的协议，因此DNS的查询非常容易被篡改，通过对UDP端口53上的DNS查询进行入侵检测，一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器（NS，Name Server）给查询者返回虚假结果。

DNS污染发生在用户请求的第一步上，直接从协议上对用户的DNS请求进行干扰。
DNS污染症状：目前一些被禁止访问的网站很多就是通过DNS污染来实现的，例如YouTube、Facebook等网站。

解决方法

对于DNS劫持，可以采用使用国外免费公用的DNS服务器解决。例如OpenDNS（208.67.222.222）或GoogleDNS（8.8.8.8）。
对于DNS污染，可以说，个人用户很难单单靠设置解决，通常可以使用VPN或者域名远程解析的方法解决，但这大多需要购买付费的VPN或SSH等，也可以通过修改Hosts的方法，手动设置域名正确的IP地址。

总结

DNS劫持就是指用户访问一个被标记的地址时，DNS服务器故意将此地址指向一个错误的IP地址的行为。范例，网通、电信、铁通的某些用户有时候会发现自己打算访问一个地址，却被转向了各种推送广告等网站，这就是DNS劫持。
DNS污染，指的是用户访问一个地址，国内的服务器(非DNS)监控到用户访问的已经被标记地址时，服务器伪装成DNS服务器向用户发回错误的地址的行为。范例，访问Youtube、Facebook之类网站等出现的状况。

访问一个Web时发生了什么

链接

• 浏览器本身它是一个客户端，当输入URL地址的时候，浏览器首先会去请求DNS服务器，通过DNS查询获取相应的域名所对应的IP地址；
• 通过这个映射的IP地址找到IP对应的服务器，并建立连接；
• 浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理，返回HTTP Response（响应）包；
• 客户端浏览器收到来自服务器的响应后就开始渲染这个Response包里的主体（body）部分，等收到全部的内容后断开与该服务器之间的连接。

http服务器的工作原理

1 客户机通过TCP/IP协议建立到服务器的TCP连接
2 客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档
3 服务器向客户机发送HTTP协议应答包，如果请求的资源包含有动态语言的内容，那么服务器会调用动态语言的解释引擎负责处理“动态内容”，并将处理得到的数据返回给客户端
4 客户机与服务器断开。由客户端解释HTML文档，在客户端屏幕上渲染图形结果

简单理解socket

我们知道两个进程如果需要进行通讯，最基本的一个前提是能唯一地标识一个进程，在本地进程通讯中我们可以使用PID来实现。
但PID只在本地唯一，网络中的两个进程PID冲突几率很大，这时候我们需要另辟它径了。我们知道IP层的ip地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样我们可以利用ip地址＋协议＋端口号唯一标示网络中的一个进程。

能够唯一标示网络中的进程后，它们就可以利用socket进行通信了，什么是socket呢？我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用，从而实现进程在网络中的通信。

socket起源于UNIX，在Unix一切皆文件哲学的思想下，socket是一种”打开—读/写—关闭”模式的实现，服务器和客户端各自维护一个”文件”，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

socket通信流程

socket是”打开—读/写—关闭”模式的实现，以使用TCP协议通讯的socket为例，其交互流程大概是这样子的：

具体来说：

• 服务器端根据地址类型（ipv4,ipv6）、socket类型、协议创建socket
• 服务器为socket绑定ip地址和端口号
• 服务器socket监听端口号请求，随时准备接收客户端发来的连接，这时候服务器的socket并没有被打开
• 客户端创建socket
• 客户端打开socket，根据服务器ip地址和端口号试图连接服务器socket
• 服务器socket接收到客户端socket请求，被动打开，开始接收客户端请求，直到客户端返回连接信息。这时候socket进入阻塞状态，所谓阻塞即accept()方法一直到客户端返回连接信息后才返回，开始接收下一个客户的连接请求
• 客户端连接成功，向服务器发送连接状态信息
• 服务器accept方法返回，连接成功
• 客户端向socket写入信息
• 服务器读取信息
• 客户端关闭
• 服务器端关闭

TCP的3次握手和4次挥手

3次握手

首先，Client端发送连接请求报文，Server端接受报文后回复ACK报文，并为这次连接分配资源。
Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

4次挥手

其中，中断连接端可以是Client端，也可以是Server端。
假设Client端发起中断连接请求，发送FIN报文。
这时候，虽然Client端没有数据要发送给Server端了，但是Server端可能还有数据要发送给Client端，所以Server端不必急着也发送FIN，而是先发送ACK就行了，表示：你的请求我收到了，但是我还没准备好关闭，请继续你等我的消息。
这个时候，Client端就进入FIN_WAIT状态，等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，”告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。
Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，在此期间，如果Server端没有收到ACK则Client端可以重传。
Server端收到ACK后，”就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

完整的过程

整个过程Client端所经历的状态如下：

而Server端所经历的过程如下：

常见问题

问题1

为什么连接的时候是3次握手，关闭的时候却是4次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭连接，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要4次握手。

问题2

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，4个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假设网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来可能的重发丢失的ACK。

UDP协议

UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。

UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。

小结TCP与UDP的区别

TCP 是一种面向连接的、可靠的、字节流服务， UDP 无连接、不可靠的数据报服务。
1. 连接方面： TCP 面向连接，交换数据之前必须通过三次握手先建立一个 TCP 连接。在一个 TCP 中仅有两方彼此通信，多播和广播不能用 TCP。 UDP 是不可靠的传输，传输前不需要建立链接，可以应用多播和广播实现一对多的通信。
2. 可靠性： TCP 提供端到端的流量控制，对收到的数据进行确认，采用超时重发，对失序的数据进行重新排序等机制保证数据通信的可靠性。而 UDP 是一种不可靠的服务，接收方可能不能收到发送方的数据报。
3.TCP 是一种流模式的协议， UDP 是一种数据报模式的协议。进程的每个输出操作都正好产生一个 UDP 数据报，并组装成一份待发送的 IP 数据报。 TCP 应用程序产生的全体数据与真正发送的单个 IP 数据报可能没有什么联系。
4. 效率上：一般 TCP 速度慢，传输过程中需要对数据进行确认，超时重发，还要对数据进行排序。 UDP 没有这些机制所以速度快。数据比例， TCP 头至少 20 个字节， UDP 头 8个字节，系统组装上 TCP 相对慢。
5. 用途上：用于 TCP 可靠性。而 UDP 速度快，视频，在线游戏多用UDP ，保证实时性。

常用的端口扫描方式

connect扫描

我们知道，常见的TCP的socket实现过程为

更本质的连接和结束的过程是如下这个样子的：

从上面两个图我们可以看出来目标主机的一个端口如果是监听状态（LISTENING或者LINSTEN），那么当我connect目标主机时就能成功，否则说明端口是关闭的。

优点： 编程简单，是需要一个API connect(),比较可靠，因为TCP是可靠协议，当丢包的时候，会重传SYN帧。

缺点： 正因为TCP的可靠性，所以当端口不存在的时候，源主机会不断尝试发SYN帧企图得到ack的应答，多次尝试后才会放弃，因此造成了扫描的时间较长。并且，connect的扫描方式可能较容易被目标主机发现。

SYN扫描

上面说到处于开放状态的端口，是在等待其它主机发送SYN帧，所以SYN扫描的原理就是想目标端口发送SUN数据帧，如果源主机收到SYN+ACK数据包，说明此端口开放，如果收到RST说明此端口关闭。由于SYN扫描并不会完成TCP三次握手过程，所以又叫半开放扫描。

优点： 速度快；如果不被防火墙过滤的话，基本都能收到应答包。

缺点： 扫描行为容易被发现；因为是自己攒包发，是在ip层的，因此不可靠，可能会丢包；实现起来比connect稍复杂。

FIN扫描

根据上述4次挥手过程，主动结束的一方会发送FIN帧。当我们发送FIN帧给一个非监听的端口时，会有RST应答，反之，发给一个正在监听的端口时，不会有任何回应。

优点： 隐蔽性好；速度快。

缺点： 只能用于Linux系统，windows系统下无效，在windows下，无论端口是否监听，都将回应RST帧，造成无法判断；不可靠，当收不到应答包时，不确定是端口在监听，还是丢包了。

4 个定时器

1.重传定时器适用于当希望收到另一端的确认。
2.坚持（ persist）定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。
3.保活（ keepalive）定时器可检测到一个空闲连接的另一端何时崩溃或重启。
4.2MSL 定时器测量一个连接处于 TIME_WAIT 状态的时间。

超时重传和快速重传

TCP是一个可靠的协议。它通过重传来实现TCP片段传输的可靠性。简单的说，TCP会不断重复发送TCP片段，直到片段被正确接收。

TCP片段丢失

接收方(receiver)可以通过校验TCP片段头部中checksum区域来检验TCP片段是否出错。TCP片段头部的checksum会校验包括IP头部、TCP头部和TCP数据在内的整个序列，确保IP地址、端口号和其他相关信息正确。如果TCP片段出错，接收方可以简单地丢弃改TCP片段，也就相当于TCP片段丢失。

TCP片段包裹在一个IP包中传输。IP包可能在网络中丢失。导致IP包丢失的原因可能有很多，比如IP包经过太多的路由器接力，达到hop limit；比如路由器太过拥挤，导致一些IP包被丢弃；再比如路由表(routing table)没有及时更新，导致IP包无法送达目的地。

下面我们要介绍两种重新发送TCP片段的机制：超时重传和快速重传。

超时重传

超时重传是TCP协议保证数据可靠性的一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。这个计时等待的时间叫做重新发送超时时间(RTO, retransmission timeout)。

发送方应该在等待多长时间之后重新发送呢？这是重新发送的核心问题。上述过程实际上有往返两个方向：1. 发送片段从发送方到接收方的传输，2. ACK片段从接收方到发送方的传输。整个过程实际耗费的时间称做往返时间(RTT, round trip time)。如果RTT是固定的，比如1秒，那么我们可以让RTO等于RTT。
但实际上，RTT的上下浮动很大。比如某个时刻，网络中有许多交通，那么RTT就增加。在RTT浮动的情况下，如果我们设置了过小的RTO，那么TCP会等待很短的时间之后重新发送，而实际上之前发送的片段并没有丢失，只是传输速度比较慢而已，这样，网络中就被重复注入TCP片段，从而浪费网络传输资源。
另一方面，如果RTO时间过长，那么当TCP片段已经实际丢失的情况下，发送方不能及时重新发送，会造成网络资源的闲置。所以，RTO必须符合当前网络的使用状况。网络状况越好，RTO应该越短；网络状况越差，RTO应该越长。

TCP协议通过统计RTT，来决定合理的RTO。发送方可以测量每一次TCP传输的RTT (从发送出数据片段开始，到接收到ACK片段为止)，这样的每次测量得到的往返时间，叫做采样RTT(srtt, sampling round trip time)。建立连接之后，每次的srtt作为采样样本，计算平均值(mean)和标准差(standard deviation)，并让RTO等于srtt平均值加上四倍的srtt标准差。

RTO = mean + 4*std

平均值反映了平均意义上的RTT，平均往返时间越大，RTO越大。另一方面，标准差越大也会影响RTO。标准差代表了RTT样本的离散程度。如果RTT上下剧烈浮动，标准差比较大。RTT浮动大，说明当前网络状况相对不稳定。因此要设置更长的RTO，以应对不稳定的网络状况。

快速重传

TCP协议有可能在计时完成之前启动重新发送，也就是利用快速重传(fast-retransmission)。快速重传机制如果被启动，将打断计时器的等待，直接重新发送TCP片段。

由于IP包的传输是无序的，所以接收方有可能先收到后发出的片段，也就是乱序(out-of-order)片段。乱序片段的序号并不等于最近发出的ACK回复号。已接收的文本流和乱序片段之间将出现空洞(hole)，也就是等待接收的空位。比如已经接收了正常片段5,6,7，此时又接收乱序片段9。这时片段8依然空缺，片段8的位置就是一个空洞。

TCP协议规定，当接收方收到乱序片段的时候，需要重复发送ACK。比如接收到乱序片段9的时候，接收方需要回复ACK。回复号为8 (7+1)。此后接收方如果继续收到乱序片段(序号不是8的片段)，将再次重复发送ACK=8。当发送方收到3个ACK=8的回复时，发送方推断片段8丢失。即使此时片段8的计时器还没有超时，发送方会打断计时，直接重新发送片段8，这就是快速重传机制(fast-retransmission)。

快速重新发送机制利用重复的ACK来提示空洞的存在。当重复次数达到阈值时，认为空洞对应的片段在网络中丢失。快速重传机制提高了检测丢失片段的效率，往往可以在超时之前探测到丢失片段，并重复发送丢失的片段。

重新分组

TCP为了提高自己的效率，允许重传时，只要传输包含重传数据报文的报文就可以，而不用只重传需要传输的报文。
比如，第二个报文段需要重传，它可以跟第三个报文段的数据重组成一个较大的报文段然后发送。

滑动窗口和拥塞窗口

滑动窗口

滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。

ack通常被理解为收到数据后给出的一个确认，事实上该确认是指接收端已经收到确认帧以前的所有的帧。举个例子，假如接收端收到 1-1024字节，它会发送一个确认号为1025的ACK，但是接下来收到的是2049-3072，它是不会发送确认号为3072的ACK,而依旧发送 1025的ACK。

滑动窗口协议如图所示：

在这个图中，我们将字节从1至11进行标号。接收方通告的窗口称为提出的窗口，它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第3字节在内的数据，且通告窗口大小为6。我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动增加或减少了窗口的大小。我们使用三个术语来描述窗口左右边沿的运动：

称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。
当右边缘向左移动时，称之为窗口收缩。

---

每个TCP连接有发送窗口和接收窗口这两个窗口。
TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。

拥塞窗口cwnd

TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制。
TCP还有一个由对端通告的接收窗口(rwnd)用于流量控制。
由于需要考虑拥塞控制和流量控制两个方面的内容，因此TCP的真正的
发送窗口=min(rwnd, cwnd)。
但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。关于cwnd的单位，在TCP中是以字节来做单位的，我们假设TCP每次传输都是按照MSS大小来发送数据的，因此你可以认为cwnd按照数据包个数来做单位也可以理解，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。

cwnd增长方式1：慢启动算法

最初的TCP在连接建立成功后会向网络中发送大量的数据包，这样很容易导致网络中路由器缓存空间耗尽，从而发生拥塞。因此新建立的连接不能够一开始就大量发送数据包，而只能根据网络情况逐步增加每次发送的数据量，以避免上述现象的发生。
具体来说，当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(Round Trip Time,RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下：

 开始           --->     cwnd = 1 经过1个RTT后   --->     cwnd = 2*1 = 2 经过2个RTT后   --->     cwnd = 2*2= 4 经过3个RTT后   --->     cwnd = 4*2 = 8

如果带宽为W，那么经过RTT*log2W时间就可以占满带宽。

cwnd增长方式2：拥塞避免

从慢启动可以看到，cwnd可以很快地增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。
TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

超时重传时确定cwnd的增长方式

当发生超时，要求重传时，出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：

1.把ssthresh降低为发送窗口的一半

2.把cwnd重新设置为1

3.首先进入慢启动

慢启动一直持续到cwnd增加到原先ssthresh的一半，然后转为执行拥塞避免

快速重传时确定cwnd的增长方式

如果收到3个重复ACK,可认为该报文段已经丢失,此时无需等待超时定时器溢出,直接重传丢失的包,这就叫【快速重传算法】。而接下来执行的不是慢启动而是直接执行拥塞避免算法，即【快速恢复算法】。

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢启动算法。

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢启动算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

http1.0和http1.1的主要区别：长连接

在HTTP1.0和HTTP1.1协议中都有对长连接的支持。其中HTTP1.0需要在request中增加"Connection：keep-alive" header才能够支持，而HTTP1.1默认支持。
基于http协议的长连接减少了请求,减少了建立连接的时间,但是每次交互都是由客户端发起的,客户端发送消息,服务端才能返回客户端消息.因为客户端也不知道服务端什么时候会把结果准备好,所以客户端的很多请求是多余的,仅是维持一个心跳，浪费了带宽。

负载均衡

链接

IP地址

子网掩码

子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。
只有在一个网络号下的计算机之间才能”直接”互通，不同网络号的计算机要通过网关（Gateway）才能互通。但这样的划分在某些情况下显得并不十分灵活。为此IP网络还允许划分成更小的网络，称为子网（Subnet），这样就产生了子网掩码。

要将一个网络划分为多个子网，因此网络号将要占用原来的主机位。例如，对于一个C类地址，它用21位来标识网络号，要将其划分为2个子网则需要占用1位原来的主机标识位。此时网络号位变为22位，主机标示变为7位。同理借用2个主机位则可以将一个C类网络划分为4个子网……那计算机是怎样才知道这一网络是否划分了子网呢？这就可以从子网掩码中看出。
子网掩码和IP地址一样有32bit，确定子网掩码的方法是其与IP地址中标识网络号的所有对应位都用”1”，而与主机号对应的位都是”0”。故A类地址的缺省子网掩码为255.0.0.0,B类为255.255.0.0,C类为255.255.255.0。

当我们要划分子网用到子网掩码M时，类子网掩码的格式如下：A类为 255.M.0.0，B类为 255.255.M.0，C类为 255.255.255.M。M是相应的子网掩码，比如255.255.255.240。

子网个数：2^m - 2：这里要减2，因为子网全为0和全为1是非法的。

可用主机数：2^(8-m) - 2：类似的，主机位全为0（子网地址）和全为1（广播地址）也是非法的。

ABC类网络地址

A类IP：从1.0.0.0 – 126.255.255.255
A类地址通常为大型网络而提供，全世界总共只有126个A类网络，每个A类网络最多可以连接16777214台主机。

B类IP：从128.0.0.0 – 191.255.255.255
(网络号不能以数字127开头，数字127是专门保留给诊断用的，如127.0.0.1是回送地址，用于回路测试）
全世界大约有16000个B类网络，每个B类网络最多可以连接65534台主机。

C类IP：从192.0.0.0 – 223.255.255.255，共有256个IP

C类地址适用于校园网等小型网络，每个C类网络最多可以有254台主机。

公有IP

A类的公有IP：
1.0.0.0~9.255.255.255
11.0.0.0~126.255.255.255
B类的公有IP：
128.0.0.0~172.15.255.255
172.32.0.0~191.255.255.255
C类的公有IP：
192.0.0.0~192.167.255.255
192.169.0.0~223.255.255.255

私有IP

A类私有IP地址：
10.0.0.0～10.255.255.255
B类私有IP地址：
172.16.0.0～172.31.255.255
C类私有IP地址：
192.168.0.0～192.168.255.255

数据传输

信道利用率

信道利用率=（发送时间）/（发送时间+往返传输时延）

序号和确认序号

主机甲与主机乙之间已建立一个TCP 连接，双方持续有数据传输，且数据无差错与丢失。若甲收到 1 个来自乙的 TCP 段，该段的序号为 1913、确认序号为 2046、有效载荷为 100 字节，则甲立即发送给乙的 TCP 段的序号和确认序号分别是（2046、 2013 ）。
乙发送给甲的报文中，确认号即是请求甲发送报文中的序列号，而其中的序列号再加有效载荷即是乙这次将要发送给甲的数据，也即甲下次要发送给乙的报文中的确认号。

报文交换和分组交换

主机甲通过1 个路由器（存储转发方式）与主机乙互联，两段链路的数据传输速率均为10Mbps，主机甲分别采用报文交换和分组大小为 10 kb 的分组交换向主机乙发送 1 个大小为 8Mb（ 1M=106）的报文。 若忽略链路传播延迟、分组头开销和分组拆装时间， 则两种交换方式完成该报文传输所需的总时间分别为（ 1600 ms、 801 ms）。

报文传输 ： 8Mb/10Mbps*2=1600ms
分组传输：一个分组的时延是10kb/10Mb/s=1ms，共计有800个分组，将最后一个接受到的总时间为801ms。

吞吐量和响应时延

假设网络带宽是128MB/s，网络单向延时为100ms, 1000个客户端(单线程)同时向服务器传输64KB大小的文件，每个请求大小为64KB，服务器磁盘并发写入速度30MB/s，在传输过程中，服务器吞吐量为 （30） MB/S ，单个请求响应时间为 （700） ms
解：
一共64K*1000 = 64MB 的数据 ， 则传输时延：(64M)/（128MB/S)=500ms , 在加上网络单向时延100ms，则64MB的数据从客户端全部到达服务器端需要600ms，如果服务器磁盘写速度无限大，那么可以保证最大吞吐量：64MB/600ms = 107MB/S ，但是服务器磁盘写速度只有30MB/S，也就是说数据到达的速度太快了，在服务器端会有阻塞，服务器端最大只能达到30MB/S的吞吐率。

第二问则在600ms的基础上加上回来的链路时延100ms，一共700ms。

HTTP常用状态码

2开头 （请求成功）

表示成功处理了请求的状态代码。
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求，可用于断点续传。

3开头 （请求被重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4开头 （请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足”期望”请求标头字段的要求。
5开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

500 （服务器内部错误）

服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

HTTPS和HTTP的区别

HTTPS (基于安全套接字层的超文本传输协议 或者是 HTTP over SSL) 是一个 Netscape 开发的 Web 协议。
你也可以说：HTTPS = HTTP + SSL
HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。

什么需要 HTTPS？

超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议，但 HTTP 是不安全的，可以轻松对窃听你跟 Web 服务器之间的数据传输。在很多情况下，客户和服务器之间传输的是敏感歇息，需要防止未经授权的访问。为了满足这个要求，网景公司(Netscape)推出了HTTPS，也就是基于安全套接字层的 HTTP 协议。

相同点

大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息、或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

不同点

HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
HTTP 是不安全的，而 HTTPS 是安全的
HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
HTTP 无需加密，而 HTTPS 对传输的数据进行加密
HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 如何工作?

称客户端为B，服务器端为S。
STEP 1: B——〉S（发起对话，协商传送加密算法）
你好,S！我想和你进行安全对话，我的对称加密算法有DES,RC5，我的密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
STEP2: S——〉B（发送服务器数字证书）
你好,B！那我们就使用DES－RSA－SHA这对组合进行通讯，为了证明我确实是S，现在发送我的数字证书给你，你可以验证我的身份。
STEP 3: B——〉S（传送本次对话的密钥）
（检查S的数字证书是否正确，通过CA机构颁发的证书验证了S证书的真实有效性后。生成了利用S的公钥加密的本次对话的密钥发送给S）
S, 我已经确认了你的身份，现在将我们本次通讯中使用的对称加密算法的密钥发送给你。
STEP4: S——〉B（获取密钥）
（S用自己的私钥解密获取本次通讯的密钥）。
B, 我已经获取了密钥。我们可以开始通信了。
STEP5: S<——>B（进行通讯）

下面再简要介绍一下信息加密相关知识。使用密钥类型加密信息的加密算法可以分为以下几类：HASH 编码、对称加密和非对称加密三类。
HASH 编码是使用HASH算法从任意长度的消息中计算HASH值的一个过程，HASH值可以说是消息的指纹，因为对于任何不同的消息，几乎总有不同的HASH值。因此在SSL通讯过程中，可以对消息的HASH值进行加密，确保传递的消息在传输过程中没有被修改。
非对称加密或称之为公钥加密使用数学上相关的两个数值来对信息进行编码（加密），其中一个数字称为公钥，另一个称为私钥。公钥加密的信息可以用私钥解密， 私钥加密的信息可以用公钥解密。由于公钥可以大面积发放，因此公钥加密在SSL加密通信中应用于对密钥的加密或者进行数字签名。
对称加密和非对称加密相比的区别在于对称加密中，加密信息和解密信息使用同样的密钥，因此该密钥无法公开。但是其具有加密、解密快速的特点。

在SSL通讯中，首先采用非对称加密交换信息，使得服务器获得浏览器端提供的对称加密的密钥，然后利用该密钥进行通讯过程中信息的加密和解密。为了保证消息在传递过程中没有被篡改，可以加密HASH编码来确保信息的完整性。

socket编程

recv

recv是个阻塞函数，返回值有3种，大于0表示接受到的字节数，等于0表示对方关闭连接，小于0表示错误。

Cookie与Session有什么区别

我们在实际生活中总会遇到这样的事情，我们一旦登录（首次输入用户名和密码）某个网站之后，当我们再次访问的时候（只要不关闭浏览器），无需再次登录。而当我们在这个网站浏览一段时间后，它会产生我们浏览的记录，而且有的网站还提供购物车的功能。这些简单实用的功能就是通过Cookie与Session实现的，接下来，让我们一起探讨一下它们是如何运行的。

概念

Cookie
指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。
Session
Session直接翻译成中文比较困难，一般都译成时域。在计算机专业术语中，Session是指一个终端用户与交互系统进行通信的时间间隔，通常指从注册进入系统到注销退出系统之间所经过的时间。以及如果需要的话，可能还有一定的操作空间。
具体到Web中的Session指的就是用户在浏览某个网站时，从进入网站到关闭这个网站所经过的这段时间，也就是用户浏览这个网站所花费的时间。因此从上述的定义中我们可以看到，Session实际上是一个特定的时间概念。
需要注意的是，一个Session的概念需要包括特定的客户端，特定的服务器端以及不中断的操作时间。A用户和C服务器建立连接时所处的Session同B用户和C服务器建立连接时所处的Session是两个不同的Session。

区别

• cookie数据存放在客户的浏览器上，session数据放在服务器上
• cookie不是很安全
• session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
• 单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的cookie不能大于3K

运行机制

Cookie机制

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

Session机制

Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

如下图所示，张三和李四分别访问该网站，在服务端会产生两个SessionID来区分该用户，而在客户端将对应的SessionID存放在Cookie中，以便我们再次访问时得到我们所需的资源。

get和post

表单提交中get和post方式的区别有5点

• get是从服务器上获取数据，post是向服务器传送数据。
• get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTPpost机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
• 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
• get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
• get安全性非常低，post安全性较高。

字节限制问题

get
是通过URL提交数据，因此GET可提交的数据量就跟URL所能达到的最大长度有直接关系。URL不存在参数上限的问题，HTTP协议规范也没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。
post
理论上讲是没有大小限制的，HTTP协议规范也没有进行大小限制，但实际上post所能传递的数据量大小取决于服务器的设置和内存大小。

forward和redirect的区别

从地址栏显示来说

forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器。
浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址。
redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL。

从数据共享来说

forward:转发页面和转发到的页面可以共享request里面的数据.
redirect:不能共享数据.

从运用地方来说

forward:一般用于用户登陆的时候,根据角色转发到相应的模块.
redirect:一般用于用户注销登陆时返回主页面和跳转到其它的网站等.

从效率来说

forward:高.
redirect:低.