• http端口是80；https端口是443
• http工作在TCP/IP参考模型中的应用层；https是基于http的，在http基础上加了SSL/TLS协议，SSL/TLS协议工作在传输层和应用层之间
• http是一种无连接(每次连接只处理一个请求，每个请求都是独立的，服务器处理请求后立即关闭连接)、 无状态(对于事务处理没有记忆能力,例如访问一个网站需要反复进行登录操作)、以C/B客户-服务器工作 模式、通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性
• http数据传输是明文的；https通过SSL/TLS协议加密数据，数据传输都是加密的
• HTTPS需要CA（证书颁发机构）颁发的证书进行加密和解密操作，而HTTP则不需要
• HTTPS数据传输效率慢(因为涉及到加密解密)；HTTP数据传输效率高；
• HTTPS中的S指定的SSL(Secure Sockets Layer安全套接字层)/TLS(Transport Layer Security传输层安全)，位于传输层和应用层之间
• TCP/IP参考模型（/主机网络层/互联网络层/传输层/应用层）

1. 语义: 规定了需要发出何种控制信息、完成的动作与做出什么样的响应(即表示要做什么?)
2. 语法: 用户数据与控制信息的结构与格式、以及数据出现的顺序(即表示要怎么做?)
3. 时序:对事件发生顺序的详细说明(即表示做的顺序)

物理层: 数据单元是比特(bit)
数据链路层: 数据单元是帧;建立数据链路连接,采用差错控制与流量控制方法,使有差错的物理线路变成无差错的数据链路
网络层: 数据单元是分组,通过路由选择算法为分组通信子网选择适当的传输路径,实现流量控制、拥塞控制与网络互联
传输层: 数据单元是报文,传输层屏蔽了低层数据通信的细节
会话层: 维护两个回话主机之间连接的建立、管理和终止、数据的交换
表示层: 负责通信系统间的数据格式变换、数据加解密、数据压缩与恢复
应用层: 控制应用程序之间的通信过程

1. 各主机都具有相同的层次
2. 不同主机的同等层具有相同的功能
3. 同一主机内相邻层之间通过接口通信
4. 每层都可以使用下层提供的服务,并向其上层提供服务
5. 不同主机的同等层通过协议来实现同等层之间的通信

主机-网络层    对应OSI模型中的  物理层、数据链路层
互联网络层     对应OSI模型中的  网络层
传输层        对应OSI模型中的  传输层
应用层        对应OSI模型中的  应用层
OSI模型中的会话层、表示层没有对应的TCP/IP模型分层

1. 主机-网络层: 负责发送和接收IP分组,TCP/IP协议对该层并没有规定具体的协议,采用的是开发的策略
   ,允许使用广域网、局域网与城域网的各种协议;
2. 互联网络层: 使用的是IP协议,IP是一种不可靠、无连接的数据报传输服务协议,
   提供的是一种“尽力而为”的服务,协议数据单元是IP分组;
3. 传输层:定义了两种不同的协议,传输控制协议-TCP与用户数据报协议-UDP,
   TCP是一种可靠的、面向连接的、面向字节流的传输层协议; UDP是一种不可靠的、无连接的传输层协议;
4. 应用层: 超文本传输协议HTTP、远程登录协议TELNET、文件传输协议FTP、简单邮件传输协议SMTP、
   域名服务协议DNS、动态主机分配协议DHCP、简单网络管理协议SNMP;

应用层    --SMTP--FTP......HTTP      DNS ...... SNMP
传输层    ----------TCP协议------------UDP协议-------   
网络层    -------------------IP协议------------------
数据链路层       底层局域网、城域网与广域网协议
物理层
三种关系:  
第一种: 应用层协议依赖于TCP协议; 例如HTTP/FTP/TELNET/SMTP  
第二种: 应用层协议依赖于UDP协议; 例如SNMP  
第三种: 应用层协议既依赖于UDP协议又依赖于TCP协议; 例如DNS  

1. IP协议是一种无连接、不可靠的分组传送服务的协议,提供的是一种“尽力而为”的服务;
   无连接意味着IP协议不维护IP分组发送后的任何状态信息,每个分组的传输过程是相互独立的、不可靠的,
   这就意味着IP协议不能保证每个IP分组都能正确、不丢失和顺序地到达目的主机;
2. IP协议是点-点的网络层通信协议;网络层需要为通信双方传输数据寻找一条路径,而这条路径
   是由多个路由器、点-点链路组成的.因此IP协议是针对源主机-路由器、路由器-路由器、路由器-目的主机之间的
   数据传输的点-点的网络层通信协议;
3. IP协议屏蔽了互联的网络在数据链路层、物理层协议与实现技术上的差异;

网络层IP协议中的数据单元是分组,IP分组由两部分组成:   
分组头: 分组头长度范围为20-60个字节(基本字节20个,可选项字节最长40个字节)   
数据: 传输的数据

URL全称是Uniform Resource Locator:统一资源定位符,简单来说URL就是资源的地址、位置,
互联网中的每一个资源都有一个唯一的URL,URL的格式: 协议://主机地址/路径

协议:不同的协议代表者不同的资源查找方式,资源传输方式
主机地址:存放资源的主机(服务器)的IP地址或者域名
路径:资源在主机（服务器）中的具体位置

file://       访问本地计算机上的资源
mailto://     访问电子邮件地址
ftp://        访问共享主机的文件资源
http://       访问远程的网络资源

请求报文结构:
请求行: 包含三个字段,请求方法/URL/HTTP版本,URL又包含了协议类型/主机名/路径或地址
请求头: 由Key/value对组成,请求头通知服务器有关于客户端请求的信息
空白行: 用CR和LF表示,最后一个请求头之后是一个空行,发送回车符和换行符，通知服务器不再有请求头
请求主体(请求正文): 请求的主要用户数据,也可以空着,(POST方式时使用，GET无请求主体)

应答报文结构:
状态行(响应行): 包含三个字段:HTTP版本/状态码/状态短语
消息报头(响应头): 包含了对服务器的描述、对返回数据的描述
响应正文(响应主体): 所谓响应主体，就是服务器返回的资源的内容

常见请求头:
    Host: 120.25.226.186:32812      //客户端想访问的服务器主机地址
    User-Agent: Mozilla/5.0         //客户端的类型，客户端的软件环境/客户端程序的信息
    Accept: text/html, /            //客户端所能接收的数据类型
    Accept-Language: zh-cn          //客户端的语言环境
    Accept-Encoding: gzip           //客户端支持的数据压缩格式
    Cookie: XXX                     //常用来表示请求者的身份
    请求体: 客户端发给服务器的具体数据，比如文件数据(POST请求才会有)

常见响应头：
    包含了对服务器的描述、对返回数据的描述
    Server: Apache-Coyote/1.1           //服务器的类型
    Content-Type: image/jpeg            //返回数据的类型
    Content-Length: 56811               //返回数据的长度
    Date: Mon, 23 Jun 2014 12:54:52 GMT //响应的时间
响应体：服务器返回给客户端的具体数据，比如文件数据

2. GET请求参数会附加在URL的查询字符串中，以键值对的形式发送给服务器,请求参数放在URL之后,以 ? 分割 URL 和 传输数据 ,传输参数数据以 & 相连;
   POST方法是把请求参数放在HTTP包的Body请求体中
3. GET请求的参数附加在URL中，URL的长度有限制，不同浏览器和服务器对URL长度的限制也不同；POST请求的参数包含在请求体中，没有像URL一样的长度限制
4. GET请求的参数暴露在URL中 因此不适合传输敏感信息；POST请求的参数包含在请求体中，相对于GET请求更安全，适合传输敏感信息

1. 非流水线: 客户端只有在接收到前一个响应时才能发出新的请求,造成服务端每响应一次都在等待下一个请求的到来
   ,连接处于空闲状态,浪费了服务器的资源;
2. 流水线: 客户端在没有收到前一个响应时就能够发出新的请求,可以像流水作业一样,连续地发送请求到服务端,
   服务端也可以连续地发送应答报文; HTTP1.1默认状态是持续连接的流水线工作方式

1XX：信息提示。表示请求已被服务器接受，但需要继续处理(100~101)
2XX：请求成功。服务器成功处理了请求(200~206)
3XX：客户端重定向码。告诉客户端访问的资源已被移动并告诉客户端新的资源位置。客户端收到重定向会重新对新资源发起请求(300~305)
4XX：客户端信息错误。客户端可能发送了服务器无法处理的东西，比如请求的格式错误，或者请求了一个不存在的资源(400~415)
5XX：服务器出错。客户端发送了有效的请求，但是服务器自身出现错误，比如Web程序运行出错(500~505)

1. 无连接的: 指每次连接只处理一个请求,服务器处理完客户端的请求并收到客户端的应答后就断开连接;
   每次请求都需要三次握手四次挥手,和服务器重新建立连接;
2. 无状态的: HTTP协议是无状态协议,无状态是指协议对于事务处理没有记忆能力,例如访问一个网站需要反复进行登录操作
3. 以客户-服务器方式工作,基于请求和响应的，即由客户端发起请求，服务端来响应;
4. 简单快速、灵活; 允许传输任意类型的数据对象,正在传输的类型由Content-Type加以标记;
5. 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性;
6. HTTP协议工作在应用层,永远都是客户端发起请求,服务端回送响应; 其实这样
   限制了HTTP协议,无法实现在客户端没有发起请求时,服务器将消息推送给客户端;

1. HTTP是应用层的协议,传输过程需要依赖传输层的TCP/UDP协议,这里我们主要讨论基于TCP协议的传输过程
2. 浏览器中输入www.baidu.com后,浏览器向DNS(域名解析)请求解析www.baidu.com的IP地址
3. DNS解析出IP地址后告诉浏览器,然后浏览器开始与服务器的80端口通过TCP的三次握手建立TCP连接
4. 连接建立后,浏览器和服务端就可以进行数据传输和交换了
5. 当不需要数据传输时,通过TCP的四次挥手断开连接

1. 客户端处于“关闭”状态,当准备发起一次TCP连接时处于“准备发送”状态,首先向处于“收听”状态的服务器端TCP进程
   发送第一个控制位“SYN=1”的“连接建立请求报文”,该报文不携带任何数据字段,但需要给报文一个随机产生
   的序号"seq=x",但是不能为0.即“SYN=1,seq=x”
   为什么随机产生的序号不能为0?
   避免因TCP连接非正常断开而可能引起的混乱,如果连接突然中断,可能有一个或两个进程同时等待对方的确认应答,而这个时候有一个新连接的序号也是从0开始,那么接收进程就有可能认为是对方重传的报文,这样就有可能造成连接过程的错误,所以TCP协议规定SYN报文序号必须随机产生,并且不能为0

2. 服务端接收到“连接建立请求报文”后,如果同意建立连接,则向客户端发送第二个控制位“SYN=1,ACK=1”的
   “连接建立请求确认报文”,确认号是"ack=x+1",表示是对第一个“连接建立请求报文”(序号"seq=x")的确认,
   同样的确认报文不携带任何数据字段,但是需要给报文一个随机产生的序号"seq=y",此时服务器处于
   “准备接收”状态,即“SYN=1,ACK=1,seq=y,ack=x+1”

3. 客户端接收到服务端的“连接建立请求确认报文”后,向服务端发送第三个控制位ACK=1“连接建立请求确认报文”,
   由于该报文是对服务带发送过来的“连接建立请求确认报文”(序号seq=y)的确认,因此确认序号为“ack=y+1”,
   同样该报文不携带任何数据字段,但是需要给报文一个序号,按照TCP协议规定,这个序号仍然为"seq=x+1",
   即“ACK=1,seq=x+1,ack=y+1”,此时客户端进入“已建立连接”状态,当服务端在接收到ACK报文之后也进入“已建立连接”状态

1. 当客户端主动提出释放TCP连接时,客户端进入“释放等待”状态,向服务端发送第一个控制位FIN=1的“连接释放请求报文”,
   提出连接释放请求,停止发送数据.“连接释放请求报文”不携带任何数据字段,但需要给报文一个序号“seq=m”,
   m等于客户端向服务端发送的最后一个字节的序号+1,即“FIN=1,seq=m”,此时客户端处于“FIN-WAIT-1”状态,
   此时客户端仍然可以接收服务端发送过来的数据,但是客户端不能再向服务端发送数据了
2. 服务端接收到“连接释放请求报文”后,需要向客户端发送“连接释放请求确认报文”,
   表示对接收到第一个连接释放请求报文的确认,因此“ack=m+1”,同样该报文不携带任何数据字段,但是需要一个
   序号"seq=n",n等于服务器发送的最后一个字节序号+1,即“ACK=1,seq=n,ack=m+1”

但是服务器端到客户端的TCP连接还没有断开,如果服务器还有数据报文需要发送时,还可以继续向客户端发送直至
发送完毕,这种状态称为“半关闭”状态,“半关闭”状态需要持续一段时间,客户端在接收到ACK报文后进入“FIN-WAIT-2”状态,
服务器端进入“CLOSE-WAIT”状态

3. 服务端高层应用程序如果没有数据需要发送时,会通知TCP可以释放连接,这时服务端向客户端发送“连接释放请求报文”,
   同样不携带任何数据字段,但需要给该报文提供序号,此时的序号取决于“半关闭”状态时,服务端是否发送过数据报文,
   因此序号假设为w,即“FIN=1,ACK=1,seq=w,ack=m+1”,此时服务端经过“LAST-ACK”状态后转回“LISTEN”监听状态

4. 客户端在接收到服务端发送的FIN报文后,向服务端发送“连接释放请求报文”,表示对服务端“连接释放请求确认报文”的
   确认,即“ACK=1,seq=m+1,ack=w+1”

1. 窃听风险: 由于是明文传输,第三方节点可以获取传输的内容;
2. 篡改风险: 第三方节点可以修改通信内容;
3. 冒充风险: 第三方节点可以冒充他人身份参与通信;

(1).保证所有信息加密传输来防止被第三方窃取;
(2)为信息添加校验机制,当被第三方破坏或修改可以被检测出来;
(3)配备身份证书来防止第三方伪装参与者通信

HTTPS并不是一个新的协议,可理解成HTTP协议的“加密版本”HTTPS协议的主要作用分两部分:

    第一就是:建立信息安全通道来保证数据的安全性;  
    第二就是:确认网站的真实性;   

进行解密; 那么服务端是怎么把密钥传递给客户端的? 答案是通过明文传输,
那么服务端在传送密钥给客户端时,密钥可能就会被第三方截取,第三方拿到密钥后就可以对加密的密文进行解密, 导致加密的数据和明文传输没什么区别; 现在问题就在于我们怎么才能把密钥安全的传递给客户端

用公钥加密的数据只有私钥才能解密; 用私钥加密的数据只有公钥才能解密;
服务端可以用客户端的公钥对数据进行加密,然后传递给客户端,客户端用私钥将服务端发送的密文进行解密,
这样就能保证数据的安全了; 但存在个问题, 非对称加密 的加解密速度比 对称加密 的要慢几十倍甚至上百倍

数据传输了,具体过程:
服务端用明文的方式将公钥A传递给客户端, 客户端收到公钥后,客户端会自己生成一个密钥B(对称加密用的密钥),
然后客户端用公钥A对这个密钥B进行加密并传递给服务端,服务端用自己的私钥(公钥A对应的私钥)去
解密这个数据就可以得到这个密钥B(对称加密的密钥),
服务端和客户端都用共同的密钥了,接下来就可以进行对称加密的数据传输了;

如果这个时候,这个公钥A被第三方截获了,公钥A被替换成了公钥a传递给了客户端,
客户端并不知情的,此时客户端接收到公钥a后,就拿公钥a对自己生成的密钥B(对称加密用的)进行加密,
然后传递给服务端,在传递给服务端的过程中,被第三方截取后,第三方就用自己的私钥(公钥a对应的私钥)
解密传输的数据得到密钥B,以后客户端和服务端进行对称加密传输过程中,由于第三方获取到了对称加密的密钥B,
所以第三方就可以对传输的加密数据进行解密,此时的加密数据传输又相当于明文传输了

那么我们就要找到一个策略来证明公钥A是属于服务端的,公钥a是不属于服务端的.
解决这个问题的方式就是 数字证书 , 需要到一个拥有公信力、大家都认可的认证中心(CA),去获取认证证书

1. 服务端向客户端发送公钥时, 会将公钥+服务器个人信息通过Hash算法生成信息摘要;
2. 为防止信息摘要被调换,服务端会用CA提供的私钥对信息摘要进行加密来形成数字签名;
3. 最后将 公钥 + 服务端个人信息 + 数字签名 合在一块形成 数字证书;
4. 当客户端接收到这个数字证书后, 用CA的公钥来对数字证书中的数字签名进行解密来得到信息摘要A
5. 对数字证书中 公钥 + 服务端个人信息进行一次Hash算法得到信息摘要B,然后
   对比信息摘要A和信息摘要B,如何相同则证明这个人是服务器,否则不是

其实服务器一开始就向CA认证机构申请了证书,而客户端也会内置这些证书

1. 客户端向服务端发起HTTPS请求,连接到服务端的443端口;
2. 服务端有一对公私钥(A/a)、数字证书,私钥服务端自己保存,将公钥A和数字证书发送给客户端;
3. 客户端通过TLS解析数字证书,来对数字证书进行检查验证其合法性,进而判断公钥A是否合格有效,
   如果无效则HTTPS传输无法继续;
4. 客户端验证公钥A合格后,客户端会随机产生一个随机值来作为密钥B(对称加密中的密钥),
   然后用公钥A对密钥B进行加密,到此HTTPS的第一次HTTP请求结束;
5. 客户端发起第二个HTTP请求,将用公钥A对密钥B进行加密后的密文发送给服务端;
6. 服务端接收到密文后,会用私钥a对密文进行解密,得到密钥B(对称加密中的密钥),然后就可以对数据进行对称加密了;
7. 服务端将对称加密后的数据发送给客户端;
8. 客户端接收到密文后,用密钥B进行解密得到明文,HTTPS中的第二个HTTP请求结束,整个HTTPS传输完成;

1. HTTP的URL以http:// 开头; HTTPS的URL以 https:// 开头;
2. HTTP是不安全的,信息是明文传输; HTTPS是安全的,具有安全性的ssl加密传输协议;
3. 连接方式不同,HTTP标准端口是 80; HTTPS的标准端口是 443;
4. 在OSI模型中,HTTP工作在应用层; HTTPS工作在传输层;
5. HTTP无需证书; 而HTTPS需要到CA申请证书,一般免费较少,需要一定费用;
6. HTTP协议连接是无状态的,HTTPS是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议。

1. UDP协议是一种无连接的、不可靠的传输层协议

    UDP协议在传输报文前不需要在通信双方建立连接,因此减少了协议开销与传输延迟
    UDP协议对报文除了提供一种可选的校验外,几乎没有提供其它的保证数据传输可靠性的措施
    如果UDP协议检测出收到的分组出错,它就会丢弃这个分组,既不确认也不通知发送端进行重传
    因此可以说UDP协议提供的是“尽力而为”的传输服务
   

2. UDP协议是一种面向报文的传输层协议

    UDP协议对应用程序提交的报文,在添加了UDP头部后构成了TPDU(传输协议数据单元),然后就直接向下提交给IP层了
    UDP对应用程序提交的报文既不合并和不拆分,而是保留原报文的长度和格式
    接收端会将发送端提交的报文原封不动的提交给接收端应用程序
    因此在使用UDP协议时,应用程序必须选择合适长度的报文,如果报文太短,则协议开销较大
    如果太长,UDP协议向IP提交的TPDU可能在IP层被分片,这样会降低协议的效率
   

UDP报文 = UDP报头(固定的8个字节) + 数据(应用程序报文)
UDP报头主要包含以下字典
1.端口号: 包含源端口号(16位-2个字节)和目的端口号(16位-2个字节)
2.长度: (16位-2字节)定义了包括报头在内的用户数据报的总长度,用户数据报的长度最大为65535字节(2^16-1)(大约63.999KB),最小为8字节,  
但UDP报头的长度固定为8字节,因此实际UDP报文的数据长度最大为65535-8=65527个字节
3.校验和:UDP校验和是可选的,UDP校验和用来检验整个用户数据、UDP报头与伪报头在传输中是否出现差错

1. 视频播放应用
   视频播放应用对数据交付实时性要求较高,而对数据交付可靠性要求较低,如果采用TCP,
   可能因为重传个别丢失的报文而加大传输延迟,反而对视频造成播放不利的影响
2. 简单的交互式应用
   有些应用可能只需要进行简单的请求和应答即可,可以选择UDP可以通过设置“定时器/重传机制”来
   处理由于IP数据分组丢失的问题,而不需要选择有确认/重传的TCP协议
3. 多播和广播应用
   UDP支持一对一、一对多、多对多的交互式通信,这点TCP协议是不支持的
   UDP协议头部长度只有8个字节,TCP协议头部长度是20个字节
   UDP协议没有拥塞控制,网络拥塞时不会要求源主机降低报文发送速率,而只会丢弃个别的报文
   这对于IP电话、实时视频会议应用都是适用的,因为这类应用要求源主机以恒定速率发送报文,要拥塞
   发生时, 允许丢弃部分报文

优点: 简洁、快速、高效
缺点:没有提供差错控制机制;在网络拥塞严重时缺乏必要的控制和调节机制

1. TCP协议支持面向连接的传输服务

    TCP在传输数据前,必须在源进程端口和目标进程端口之间建立一条TCP传输连接,每个TCP传输连接用双方端口号来标识,
    因为TCP是建立在不可靠的网络层IP协议之上,IP协议不能提供任何可靠性保障
    机制,所以传输的可靠性只能TCP自己来解决了
   

2. TCP协议支持字节流的传输

    字节流相当于一个管道,从一端放入什么内容,从另一端可以照原样取出什么内容,它描述的
    是一个不出现流失、重复和乱序的数据传输过程.
    如果是键盘输入数据,那么应用程序将逐个字符的提交给发送端,如果是文件,那么数据可能是逐行或逐块交付给发送端,
    应用程序和TCP每次交互的数据长度可能都不相同.
    TCP协议将应用程序提交的数据看成是一连串的、无结构的字节流,为了支持字节流传输,发送端和接收端都需要使用缓存
    发送端使用发送缓存来存储应用程序送来的数据,发送端不可能为发送的每个写操作创建一个报文段,而是选择
    将几个写操作组合成一个报文段,然后提交给IP协议,由IP协议封装成IP分组,然后传输给接收端.
    接收端IP协议将接收的IP分组拆封后,将数据段提交给接收端的TCP协议,接收端TCP协议
    将接收的字节存储在接收缓存中,应用程序使用读操作将接收数据从接收缓存中读出.
    TCP协议将数据看成是一连串的、无结构的字节流,因此接收端应用程序的数据字节的起始
    和终结位置必须由应用程序自己确定.
   

3. 支持全双工通信

    TCP协议允许通信双方的应用程序在任何时候都可以发送数据,由于双方都设置有发送和
    接收缓冲区,应用程序将要发送的数据字节提交给发送缓冲区,数据字节的实际发送过程
    由TCP控制,而接收端在正确接收到数据字节后,将它缓存在接收缓冲区,高层应用从缓冲区读取数据
   

4. 支持同时建立多个并发的TCP连接

    TCP协议支持同时建立多个连接,如在服务器端,一个服务器必须可以同时处理多个客户的访问
    .TCP协议支持一个服务器与多个客户端同时建立多个TCP连接,也支持一个
    客户端与多个服务器同时建立多个TCP连接,TCP协议软件将分别管理多个TCP连接
   

5. 支持可靠的传输服务

    TCP使用确认机制检查数据是否安全和完整的到达,并且提供了拥塞控制功能,
    TCP支持可靠数据传输的关键是对发送和接收的数据进行跟踪、确认和重传.
    注意:TCP协议建立在不可靠的网络层IP协议之上,一旦IP协议及以下层出现传输错误,TCP协议只能不断的
    进行重传,视图弥补传输中出现的问题.
    传输层传输的可靠性是建立在网络层基础上的,同时也就会收到它们的限制
   

   TCP报文 = TCP头部(TCP报头) + 数据
   TCP头部(TCP报头)长度为20~60个字节,其中固定长度20个字节,可选项占用的字节可变,最多为40个字节

1. 端口号: 源端口号(16位-2个字节) + 目标端口号(16位-2个字节)
2. 序号: 长度为32位(4个字节),范围为0~2^32-1.

双方都需要产生一个随机的初始序号(ISN);因为初始序号是随机产生的,所以一个TCP连接的通信双方的序号是不同的;
例如:
需要发送420个字节的文件,初始序号(ISN)位1010,分5个报文段发送,前4个报文段长度都是100个字节,
第5个报文段长度为20个字节,那么第一个报文段的序号即1010-1110,依次为(1111-1211)、(1212-1312)、
(1313-1413)、(1414-1434)

3. 确认号: 长度32为(4个字节)

例如:
主机A向主机B发送了序号为200~500的报文段,主机B正确接收到后,主机B在下一个发送到主机A的报头的确认号
写成“501(500+1)”,主机A在接收到该报文后,读到确认号为“501”时,就认为主机B已经正确接收到最后一个字节的
序号为500及以前所有的字节,希望接下来发送以序号为501开始的报文段,这就是网络协议中典型的 捎带确认方法

4. 报头长度:
   报头长度字段的长度为4位,TCP报头长度是以4字节为一个单元来计算的,实际报头长度在20~60个字节,因此这个字段的值
   在5(45)~15(415)之间
5. 保留: 保留字段长度为6位
6. 控制: 控制字段定义了6种不同的控制位或标志,占6位
7. 窗口:窗口字段长度为16位

窗口字段值是准备接收下一个TCP报文段的接收端,通知即将发送报文段的发送端,下一次最多可以发送报文段的字节数,
发送端将根据接收端通知的窗口值来调整自己的发送窗口值大小,窗口字段值是动态变化的

8. 紧急指针: 长度为16位(2个字节)

9. 选项: 即可选项,最多有40个字节
10. 校验和: 长度为16位(2个字节)

最多可以在报文的数据字段中放置的数据字节数量,这个值与窗口大小无关;MSS是TCP报文中数据部分的最大字节数
限定值,不包括报头长度;

1. 协议开销:
   TCP报文的长度=TCP报头+数据部分,TCP报头长度是20~60个字节,如果报头值取
   一个折中的值40个字节为例,如果MSS值也选择40个字节,那么每个报文段的50%用来传输数据,
   显然,MSS值太小会增加协议开销
2. IP分片:
   TCP报文是要通过IP分组传输的,如果MSS值选择太大,受到IP分组长度的限制,
   较长的报文段在IP层将会被分片传输,分片的结果同样会增加网络层的开销和传输出错的概率;
3. 发送和接收缓冲区的限制:
   为保证TCP面向字节流传输,建立TCP连接的发送端和接收端都必须
   设置发送和接收缓冲区,MSS值的大小直接影响到发送和接收缓冲区设置的大小和使用效率;
4. MSS的默认值:
   确定的默认MSS值为536个字节,考虑到报头固定长度20个字节,那么默认的报文段长度就是556字节,对于某些应用,
   MSS值也许不一定适合,开发人员需要选择其它MSS值,这个要求可以在建立TCP连接时使用SYN(控制中的同步位)
   报文中最大长度选项来协商,TCP允许连接的双方可以选择不同的MSS值;

这个连接,进行全双工的字节流传输,
为了保证TCP工作正常、有序的进行
TCP设置了“保持计时器”来防止TCP连接处于长时期空闲,“保持计时器”一般是服务端来设置,当服务端收到客户端的
报文后,就将“保持计时器”复位,如果服务端过了设定的时间没有收到客户端的信息,它就会发送“探测报文”,
如果发送10个“探测报文”(每一个间隔75秒)还没有响应,就会认为客户端出现故障,进而终止该连接

它并不认为这个连接马上就真正的关闭,这时,客户端进入“TIME-WAIT”状态,需要再等待
两个”最长报文寿命(MSL)“时间后,才真正进入“CLOSE关闭”状态

为了确保服务端在最后阶段发送给客户端的数据,以及客户端发送给服务端最后一个ACK报文都正确的被接收,
防止因个别报文传输错误导致连接释放失败

IP分组在传输过程中出错是不可避免的,所以TCP协议必须提供差错控制、确认与重传功能来保证字节流的正确.
TCP协议通过滑动窗口机制来跟踪和记录发送字节的状态,实现差错控制功能,
TCP协议工作时让应用进程将数据作为一个字节流传送给它,而不是限制应用层数据的长度,
应用进程不需要考虑发送数据的长度,这些都是由TCP协议来负责将这些字节分段打包的

1. TCP协议使用以字节为单位的滑动窗口协议来控制字节流的发送、接收、确认与重传过程
2. TCP使用两个缓存和一个窗口来控制字节流的传输过程,发送端的缓冲区用来存储应用进程准备发送的数据,
   发送端对这个缓冲区设置了一个发送窗口,只要这个窗口值不为0就可以发送报文段,TCP接收端也有个缓冲区,
   接收端将正确接收到的字节流写入缓存等待应用进程读取,接收端也设置了一个接收窗口,
   窗口值等于接收缓存可以继续接收多少字节流的大小
3. 接收端通过TCP报头通知发送端: 已经正确接收的字节号,以及发送端还能够连续发送的字节数,
   接收窗口大小由接收端根据缓存区剩余的空间大小、应用进程读取数据的速度决定,发送窗口大小取决于
   接收窗口的大小,但是发送端的窗口值大小 <= 接收端的窗口值大小
4. TCP协议是面向字节流的,但是不可能每传送一个字节,就对这个字节进行确认,它是将字节流分段,
   一个段的多个字节打包成一个TCP报文段一起传送、一起确认,TCP协议通过报头的“序号”来标示发送的字节,
   用“确认号”来标识哪些字节已经被正确接收

1. 已经发送,且已得到确认的字节: 接收端已经正确接收,并给发送端发送了确认消息
2. 已经发送,但没有被确认的字节: 发送端已经发送,但还没有收到接收端的的确认消息
3. 尚未发送,但接收端表示接收缓冲区已准备好: 如果发送端准备好就可以立即发送的字节
4. 尚未发送,且接收端也未做好接收准备的字节:

1. 发送窗口:字节流传输状态中的 第2类和第3类字节数之和就是发送窗口的长度,即已经发送,但发送端还没有接收到接收端的确认信息 + "尚未发送,但接收端缓冲区已准备好了"
2. 可用窗口: 可用窗口的长度等于 第3类字节数的长度,即尚未发送,但接收端缓冲区已准备好了,发送可用窗口字节之后,传输的字节流的状态就会随着发生改变,每次都是向后移动

1. TCP使用发送与接收缓冲区,以及滑动窗口机制来控制TCP连接上的字节流传输
2. TCP滑动窗口是面向字节的,它可以起到差错控制的作用
3. 接收端可以在任何时候发送确认,窗口大小可以由接收端根据需要增大或减少
4. 发送端窗口值可以小于接收端窗口值,但不能超过接收端窗口值,发送端可以根据自身的需要来决定

报文是:报文段1(0-150)、报文段2(151-300)、报文段3(301-400)、报文段4(401-500)、报文段5(501-700),
而接收端接收到的是报文段1(0-150)、报文段3(301-400)、报文段5(501-700),
报文段2和报文段4丢失了,针对丢失报文的情况主要采用以下两种方式进行处理

1. 拉回方式:
   需要在报文段2(151-300)丢失时,不管之后的报文段是否接收正确并成功,都要求从报文段2(151-300)开始,
   重传之后的报文段,显然,拉回方式效率很低
2. 选择重传方式:
   允许接收端在收到字节流序号不连续时,如果这些字节的序号都在接收窗口之内,则首先完成接收窗口内字节的接收,
   然后将丢失的字节序号通知发送端,发送端只需要重传丢失的报文段,而不需要重传已经接收的报文段

首先将该报文的一个副本放入重传队列,同时启动一个重传计时器,重传计时器设定一个值,例如400ms,然后开始倒计时,
当重传计时器到0之前收到接收端发送的确认报文,表示该报文传输成功;如果在计时器到0之时还没收到确认报文,
表示报文传输失败,这时准备重传该报文;

如果设置值过大(时间太长),就造成一个报文已经丢失,而发送端长时间的等待,造成效率降低的想象;
所以设定重传计时器值的”恰当性“很重要也很困难

1. 如果一个主机同时与两个主机奖励两条TCP连接,那么它就需要分别为每个TCP连接启动一个重传计时器,
   因为两个TCP连接的报文发送和确认信息返回的往返时间相差很大,例如一个TCP连接时用于本地局域网传输文本文件,
   一个TCP连接用于访问远程的Web服务器视频文件,所以需要设置两个不同的重传计时器
2. 由于Internet在不同时间段的用户数量变化很大,流量与传输延迟变化也很大,因此即便是相同的
   两个主机在不同时间建立的TCP连接,完成同样的Web访问操作,客户端与服务端之间的报文传输延迟也不会相同
3. 传输层面对的是复杂的互联网络结构,要在只能够提供“尽力而为”服务的IP之上处理端-端报文传输问题,
   报文往返时间在数值上离散较大也是很自然的事
4. 基于以上原因,设置重传计时器的数值是很困难的,TCP不会采用简单的静态方法,必须采用动态的自适应方法,
   不断调整和设置重传计时器的超时重传时间

将该值写到TCP报头中,将当前接收端的接收状态通知发送端,发送端的发送窗口不能够超过接收窗口的数值,这里有两种情况:

1. 当接收端应用程序从接收端缓冲区读取字节的速度大于或等于字节到达的速度时,
   接收端需要在每个确认报文中发送一个“非零的窗口”通告
2. 当发送端发送的速度比接收端接收速度快时,接收端缓冲区将被全部占用,之后到达的字节将因为缓冲区溢出而丢失,
   这时接收端必须发送一个“零窗口”的通知.发送端接收到“零窗口”通知时,停止发送,
   直到下一次接收到接收端重新发送的一个“非零窗口”通知为止

1. 接收端通知发送端接收窗口值(rwnd=2500),表示接收端已经做好连续接收2500字节的准备
2. 发送端接收到rwnd=2500的通知后,准备发送2500字节的数据,假设报文段长度为1000字节,其它两个报文段
   长度为1000字节,而第三个报文段长度为500字节
3. 接收端在分别接收到序号为1-1000、1001-2000、2001-2500的三个报文段后,存放在输出队列中(接收端缓冲区),
   等待应用程序读取,应用程序忙而不能及时读取,TCP输出缓冲区被占满,不能接收新的报文段,因此,
   接收端在向发送端发出对序号1-2500的字节正确接收确认的同时,发送一个“零窗口”(rwnd=0)的通知
4. 发送端接收到对序号1-2500的字节确认报文后,直到三个报文段都已经被正确的接收,同时根据rwnd=0的通知,
   将发送端窗口也置0,停止发送,知道接收到接收端重新发送的一个“非零窗口”通知为止
5. 当接收端的应用程序从接收缓冲区中读取了1000字节的数据,腾空了1000个字节的存储空间,
   接收端发出rwnd=1000的“非零窗口”通知
6. 发送端接收到rwnd=1000的通知后,发送序号为2501-3500的字节,
7. 这个过程一直持续下去,知道数据全部被传输完成为止

就造成了死锁,为了防止死锁现象出现,TCP设置了一个坚持计时器

发送端的TCP就发送一个“零窗口探测报文”,该报文只有一个字节的数据,它有一个序号,
但它的序号不需要确认.“零窗口探测报文”作用就是提示接收端:“非零窗口”通知丢失,必须重传.

的应答,则需要发送第二个“零窗口探测报文”,直到接收到“非零窗口”通知为止

问题,TCP协议必须解决好“什么时候”、“发送多长报文段”的复杂问题.

1. 第一步将这1个字节的数据+20个字节的报头(报头长度20-60个字节,这里取最小的一个长度)封装在一个报文段中;
2. 在网络层将报文段再加上20个字节的分组头封装到一个IP分组中;
3. 接收端接收之后没有数据要发送了,但也要立即返回一个40个字节的确认分组,其中TCP报头占20个字节,IP分组头占20个字节
4. 接收端向发送端发送一个窗口更新报文,通知将窗口向前移1字节,这个分组的长度也是40个字节
5. 如果再发送1字节的数据,那么发送端返回一个41字节的分组,作为对窗口更新报文的应答

1.发送端发送1字节数据(41个字节)、
2.接收端回执确认接收报文(40个字节)、
3.接收端发送窗口更新报文(40个字节)、
4.发送端发送1个字节数据(41个字节)作为对窗口更新报文的应答).
这种方法显示时不合适的

涉及链路带宽、路由器处理分组的能力、节点缓存与处理数据能力、路由选择算法、流量控制算法等一系列问题,
所以人们将对网络资源的需求 > 网络可用资源作为网络出现拥塞的条件.
当进入网络的流量增加,会使网络通信负荷过重,进而导致报文传输延时增大或丢弃.
报文的差错确认和重传又会进一步加剧网络的拥塞

流量控制可以很好的解决发送端与接收端之间的端-端报文发送和处理速度的协调,但无法控制进入网络的总体流量

1. 负载: 表示单位时间进入网络的字节数
2. 吞吐量: 单位时间内通过网络输出的字节数
3. 当负载 < 吞吐量(正常);
   当吞吐量的增长 < 网络负载的增加流量(出现轻度拥塞);
   当网络负载继续增加而吞吐量不变时(达到饱和状态,即拥塞);
   当网络负载继续增加到一定程度时,网络吞吐量为0(系统出现死锁)

应该取“通知窗口”与“拥塞窗口”中的最小值.在没有发生拥塞情况下,
接收端的通知窗口和拥塞窗口应该一致,发送端的拥塞窗口大小如何确定那?

当主机发送数据时,它对网络的负载状态是不清楚的,会试探着采用由小到大逐步增加拥塞窗口值的方法

1. 将发送端发送报文到接收端,接收端在规定时间内返回了确认报文为一个往返的话,在TCP连接的初始化时,
   将慢开始的初始值设定为1,第一个往返首先将拥塞窗口设值为2,然后向接收端发送两个最大报文段,
   如果接收端在定时器允许的往返时间内返回确认,表示网络没有出现拥塞,拥塞窗口值按照二进制指数方式增长,
   即此时的拥塞窗口值为4,依次类推.一旦没有收到确认报文,就表明网络出现拥塞

2. 每一次发送的往返时间(RTT)是不同的,在拥塞控制中,往返时间应该是连续发送多少个报文段,
   到接收到所有发送报文段确认消息需要的时间,往返时间取决于连续发送报文段的多少

3. 慢开始的“慢”并表示指将拥塞窗口值从1开始,按照二进制指数方式增长的速度为“慢”,
   而是指以一种试探着逐步增大拥塞窗口值的方式比突然将很多报文发送网络上的情况要“慢”

4. 为避免拥戴窗口值增长过快引起网络拥堵,TCP定义了一个慢开始阀值(slow-start threshold),并且规定如下

    拥塞窗口值 < 慢开始阀值时, 使用慢开始算法
    拥塞窗口值 > 慢开始阀值时, 停止使用慢开始算法,使用拥塞控制算法
    拥塞窗口值 = 慢开始阀值时, 既可以使用慢开始算法,也可以使用拥塞控制算法
    在慢开始阶段,如果长度为32出现超时,发送端就可以将慢开始阀值设置为出现拥塞值32的一半,即慢开始阀值变为16
   

拥戴控制算法采用的是每增加一个往返时间就将拥塞窗口值加1,在这个阶段,拥塞窗口呈线性增加的规律缓慢增长,
只要发现接收端没有按时返回确认就认为出现网络拥塞,将慢开始阀值设置为发生拥塞时将拥塞窗口值的一半,
并将重新进入下一轮的慢开始过程

拥塞窗口值呈线形方式增长(每次增加1),当出现拥塞时,将慢开始阀值设置为
出现当前拥塞窗口值的一半,然后再次进入慢开始阶段

执行慢开始策略,同时将慢开始阀值减小到一半,以延缓拥塞的出现

这时不能根据一个M3的超时判断网络出现拥塞,这种情况下,就要采用快重传与快恢复的拥塞控制算法

1. 当接收端正确接收到M1、M2报文段,而没有接收到M3时,接收端在返回对M1、M2的确认之后,接收到M4,
   但仍然没有接收到M3情况下,接收端不能对M4进行确认,因为M4属于乱序的报文,根据“快重传”算法的规定,
   接收端应该及时向发送端连续三次发出对M2的“重复确认”,要求发送端尽快重传未被确认的报文(M3)
2. 当接收端发送第一个对M2的“重复确认”时,发送端立即将拥塞窗口值设置为最大拥塞窗口值的1/2,执行“拥塞避免”算法,
   拥塞窗口值按照线性方式增长
3. 当接收端发送第二个对M2的“重复确认”时,发送端立即减少拥塞窗口值,设置为出现拥塞时拥塞窗口值的一半,
   执行“拥塞避免”算法,拥塞窗口值按照线性方式增长
4. 当接收端发送第三个对M2的“重复确认”时,发送端立即减少拥塞窗口值,设置为出现拥塞时拥塞窗口值的一半,
   执行“拥塞避免”算法,拥塞窗口值按照线性方式增长

接收窗口值于拥塞窗口值中最小的一个

一个read可能会读到多个send

UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中

它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被 TCP 拆分成多个包进行发送，也有可能 把多个小的包封装成一个大的数据包发送，这就会出现粘包拆包的问题

• 1.定长: 每个发送的数据包都定义固定长度，如果包内容不够长时，可以用空字符或者空格填充
• 2.分隔符: 可以在数据包之间设置边界,如添加特殊符号,这样，接收端通过这个边界就可以将不同的数据包拆分开
• 3.包头包长: 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段， 便知道每一个数据包的实际长度了

1. 客户/服务器(C/S)模式: 采用C/S模式主要是因为网络资源分布的不均匀性,(硬件/软件/数据)能力弱的充当客户,能力强
   的充当服务器
2. 对等(P2P)模式: P2P是网络节点之间采用对等的方式,通过直接交换信息达到共享计算机资源和服务的工作模式;主要应用
   在实时通信、协同工作、内容分发和分布式计算等领域

1. P2P通信模式: 指P2P网络中对等节点之间直接通信的能力
2. P2P网络: 指在Internet中由对等节点组成的一种动态的逻辑网络
3. P2P实现技术:指为实现对等节点之间直接通信的功能和特定的应用所涉及的协议与软件

                 C/S    服务器    C/S
        客户端 -----------P2P-----------客户端

1. C/S工作模式中信息资源的共享是以服务器为中心的,服务提供者和服务使用者之间的界限清晰
2. P2P工作模式淡化服务提供者与服务使用者的界限; 所有节点同时身兼服务提供者与服务使用者的双重身份,即对等地位
3. 两者在传输层以下各层的协议都相同,差别主要表现在应用层,传统C/S应用层协议有DNS/SMTP/FTP/Web等,
   P2P网络应用层协议主要有支持文件共享类Napster与BitTorrent服务的协议、支持多媒体传输类Skype服务的协议等
4. P2P网络并不是一个新的网络结构,而是一种新的网络应用模式,是在IP网络上构建的一种逻辑的覆盖网

1. 基础实施类

    域名服务DNS协议: 支持Internet运行的全局基础设施类应用层协议
    动态主机配置协议DHCP: 支持各个网络系统运行的局部基础设施类应用层协议
   

2. 网络应用类(主要分两类)

    1.基于C/S工作模式: 网络终端协议(TELNET)/文件传输协议(FTP)/Web服务协议(HTTP)/电子邮件协议(SMTP)
    2.基于P2P工作模式: 文件共享/即时通信/流媒体/分布式计算/协同工作/共享存储
   

3. 网络管理类

    简单网络管理协议SNMP
   

1. 域名空间: 定义一个包括所有可能出现的主机名字的域名空间
2. 域名注册: 保证每台主机域名的唯一性
3. 域名解析: 提供一种有效的域名与IP地址转换机制
4. 基于此,DNS包括三个组成部分: 域名空间、域名服务器、域名解析程序