关注凡猫学院：加微信+17031115530，拉测试微信群交流
****************************************************************************************************************
传输控制协议TCP
TCP 主要特点:
面向连接的运输层协议
每一条TCP 连接只能有2 个端点, TCP 是点对点的
提供可靠交付
全双工通信
面向字节流
TCP 的工作流程
TCP 字节流
TCP 的连接
TCP 连接的端点叫套接字(socket)
socket = (IP 地址: 端口号)
每一条TCP 连接唯一地被通信两端的两个端点(socket)所确定. 即:
TCP 连接::= {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}
TCP 报文段的首部
微信+17031115530，拉测试微信群交流
TCP 报文段的首部
源端口和目的端口: 同UDP 端口作用
序号: 本报文段的数据的第一个字节的序号
确认号: 期望收到对方下一个报文段的第一个数据字节的序号
若确认号= N, 则表明: 到序号N-1 为止的所有数据都已正常收到
数据偏移: TCP 报文段的首部长度
保留: 以后用, 目前为0
紧急URG : 若URG = 1 时, 说明紧急指针字段有效, 告诉系统这是紧急数据, 应尽快传送. 例
如突然要中断传送
确认ACK : ACK = 1 时确认号才有效, ACK = 0 时确认号无效. TCP 规定, 连接建立后所有传送的
报文段都必须把ACK 置1
推送PSH : 若PSH = 1, 则接收方收到报文段之后不再等到整个缓存满而是直接向上交付
复位RST : 当RST = 1, 说明TCP 连接有严重错误, 必须释放连接再重连
同步SYN : 在连接建立时用来同步序号. 当SYN = 1, ACK = 0 时表明这是一个连接请求报文段,
对方若同意建立连接, 则在响应的报文段中置SYN = 1, ACK = 1
终止FIN : 当FIN = 1, 表明此报文段的发送方数据已发送完毕, 并要求释放连接
窗口: 告诉对方: 从本报文段首部中的确认号算起, 接收方目前允许对方发送的数据量.
这是作为接收方让发送方设置其发送窗口的依据
微信+17031115530，拉测试微信群交流
检验和: 同UDP, 检验首部和数据部分
紧急指针: 当URG = 1 时有效, 指出紧急数据的末尾在报文段的位置
选项: 最大可40 字节, 没有则为0
最大报文段长度MSS(Maximum Segment Size) : 每一个TCP 报文段中数据字段的最大长度,
若不填写则为默认的536 字节.
窗口
TCP 中很重要的一个概念, 那就是窗口(发送窗口和接收窗口)
窗口
由于停止等待协议非常低效, 于是衍生出窗口这一概念. 上图为发送方维持的发送窗口, 位
于发送窗口的5 个分组都可以连续发送出去而不需要等待对方的确认. 每收到一个确认, 就
把发送窗口前移一个分组的位置. 这大大提高了信道利用率!
接收方不必发送每个分组的确认报文, 而是采用累积确认的方式. 也就是说, 对按序到达的
最后一个分组发送确认报文.
超时重传
如果发送方等待一段时间后, 还是没收到ACK 确认报文, 就会启动超时重传. 这个等待的
时间为重传超时时间(RTO, Retransmission TimeOut).
然而, RTO 的值不是固定的, 这个时间总是略大于连接往返时间(RTT，Round Trip Time). 假设
报文发送过去需要5 秒, 对方收到后发送确认报文回来也需要5 秒, 那么RTT 就为10 秒, 那
这RTO 就要比10 秒要略大一些. 那么超过RTO 之后还没有收到确认报文就认为报文丢失了,
就要重传.
流量控制
利用滑动窗口和报文段的发送时机来进行流量控制.
微信+17031115530，拉测试微信群交流
拥塞控制
发送方维持一个拥塞窗口cwnd, 发送窗口= 拥塞窗口.
慢开始: cwnd = 1, 然后每经过一个传输轮次就翻倍
拥塞避免: 让cwnd 缓慢增大, 每经过一个传输轮次就+1
慢开始门限ssthresh :
当cwnd < ssthresh, 使用慢开始算法
当cwnd > ssthresh, 使用拥塞避免算法
当cwnd = ssthresh, 随意
只要判断网络出现拥塞, 把ssthresh 设为当前发送拥塞窗口的一半(不能小于2), 并把cwnd
设为1, 重新执行慢开始算法.
除了慢开始和拥塞避免算法外, 还有一组快重传和快恢复算法:
快重传: 接收方及时发送确认, 而发送方只要一连收到三个重复确认, 马上重传
快恢复: 当发送方一连收到三个重复确认时, ssthresh 减半, cwnd 设为ssthresh.
TCP 三次握手
TCP 三次握手建立连接和四次挥手断开连接是面试爱问的知识点.
微信+17031115530，拉测试微信群交流
Q : 为什么要三次握手, 两次不可以吗?
A : 试想一下, A 第一次发送请求连接, 但是在网络某节点滞留了, A 超时重传, 然后这一次一
切正常, A 跟B 就愉快地进行数据传输了. 等到连接释放了以后, 那个迷失了的连接请求突然
到了B 那, 如果是两次握手的话, B 发送确认, 它们就算是建立起了连接了. 事实上A 并不会
理会这个确认, 因为我压根没有要传数据啊. 但是B 却傻傻地以为有数据要来, 苦苦等待.
结果就是造成资源的浪费.
更加接地气的解释就是: A 打电话给B
第一次握手: 你好, 我是A, 你能听到我说话吗
第二次握手: 听到了, 我是B, 你能听到我说话吗
第三次握手: 听到了, 我们可以开始聊天了
三次握手其实就是为了检测双方的发送和接收能力是否正常, 你说呢?
TCP 四次挥手
微信+17031115530，拉测试微信群交流
Q : 为什么要四次挥手, 而不是两次, 三次?
A :
首先, 由于TCP 的全双工通信, 双方都能作为数据发送方. A 想要关闭连接, 必须要等数据都
发送完毕, 才发送FIN 给B. (此时A 处于半关闭状态)
然后, B 发送确认ACK, 并且B 此时如果要发送数据, 就发送(例如做一些释放前的处理)
再者, B 发送完数据之后, 发送FIN 给A. (此时B 处于半关闭状态)
然后, A 发送ACK, 进入TIME-WAIT 状态
最后, 经过2MSL 时间后没有收到B 传来的报文, 则确定B 收到了ACK 了. (此时A, B 才算是
处于完全关闭状态)
PS : 仔细分析以上步骤就知道为什么不能少于四次挥手了.
Q : 为什么要等待2MSL(Maximum Segment Lifetime)时间, 才从TIME_WAIT 到CLOSED？
A : 在Client 发送出最后的ACK 回复，但该ACK 可能丢失。Server 如果没有收到ACK，将不
断重复发送FIN 片段。所以Client 不能立即关闭，它必须确认Server 接收到了该ACK。Client
会在发送出ACK 之后进入到TIME_WAIT 状态。Client 会设置一个计时器，等待2MSL 的时间。
如果在该时间内再次收到FIN，那么Client 会重发ACK 并再次等待2MSL。MSL 指一个片段在
网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到2MSL，
Client 都没有再次收到FIN，那么Client 推断ACK 已经被成功接收，则结束TCP 连接。
更加接地气的解释:
第一次挥手: A 告诉B, 我没数据发了, 准备关闭连接了, 你要发送数据吗
第二次挥手: B 发送最后的数据
第三次挥手: B 告诉A, 我也要关闭连接了
第四次挥手: A 告诉B 你可以关闭了, 我这边也关闭了
应用层
微信+17031115530，拉测试微信群交流
应用层协议最著名的就是HTTP, FTP 了, 还有一个重要的DNS
域名系统(DNS, Domain Name System)
DNS 能将域名(例如, www.jianshu.com)解析成IP 地址.
域名服务器分类
根域名服务器: 最高层次的域名服务器
顶级域名服务器: 如其名
权限域名服务器: 负责一个区的应服务器
本地域名服务器: 主机发送DNS 查询请求就是发给它
DNS 查询
主机向本地域名服务器的查询一般都是采用递归查询
本地域名服务器向根域名服务器的查询通常是采用迭代查询
递归查询: B 问A 广州怎么去, A 不知道, A 就问C, C 不知道就问D...直到知道了再一层一层
转告直到A 告诉B.
迭代查询: B 问A 广州怎么去, A 不知道, A 就告诉你可以去问C, 然后B 就去问C, C 不知道,
C 就告诉你可以去问D, 然后B 就去问D...直到B 知道为止
DNS 查询例子: 域名为x.tom.com 的主机想知道y.jerry.com 的IP 地址
微信+17031115530，拉测试微信群交流
主机x.tom.com 先向本地域名服务器dns.tom.com 进行递归查询
本地域名服务器采用迭代查询. 它先问一个根域名服务器
根域名服务器告诉它, 你去问顶级域名服务器dns.com
本地域名服务器问顶级域名服务器dns.com
顶级域名服务器告诉它, 你去问权限域名服务器dns.jerry.com
本地域名服务器问权限域名服务器dns.jerry.com
权限域名服务器dns.jerry.com 告诉它所查询的主机的IP 地址
本地域名服务器把查询结果告诉主机x.tom.com
PS : 该查询使用UDP, 并且为了提高DNS 查询效率, 每个域名服务器都使用高速缓存.
URL
URL 的格式: <协议>://<主机>:<端口>/<路径>, 端口和路径有时可省略.
使用HTTP 协议的URL : http://<主机>:<端口>/<路径>, HTTP 默认端口号是80
HTTP 协议
HTTP 是面向事务的, 即它传输的数据是一个整体, 要么全部收到, 要么全部收不到.
万维网的工作过程
微信+17031115530，拉测试微信群交流
每一次HTTP 请求就需要建立一次TCP 连接和释放TCP 连接.
HTTP 是无连接, 无状态的. 每一次请求都是作为一次新请求.
HTTP/1.0 缺点: 无连接, 每一次请求都要重新建立TCP 连接, 所以每一次HTTP 请求都要花
费2 倍RTT 时间(一次TCP 请求, 一次HTTP 请求)
HTTP/1.1 : 使用持续连接, 即保持TCP 连接一段时间.
HTTP/1.1 持续工作的两种工作方式: 非流水线方式和流水线方式
非流水线方式: 收到一个请求的响应再发下一个请求, 效率低, 浪费资源
流水线方式: 能够同时发送多个请求, 效率高
HTTP 的GET 和POST
GET 请求通常用于查询、获取数据，而POST 请求则用于发送数据
GET 请求的参数在URL 中, 因此绝不能用GET 请求传输敏感数据, 而POST 请求的参数在请
求头中, 安全性略高于GET 请求
ps : POST 请求的数据也是以明文的形式存放在请求头中, 因此也不安全
Cookie
万维网使用Cookie 来跟踪用户, 表示HTTP 服务器和用户之间传递的状态信息.
Cookie 工作原理:
1. 用户浏览某网站, 该网站的服务器为用户产生一个唯一的识别码, 并以此为索引在服务
器后端数据库中产生一个项目2. 返回给用户的HTTP 响应报文中添加一条"Set-cookie", 值
为该识别码, 如1233. 用户的浏览器将该cookie 保存起来, 在用于继续浏览该网站时发送的
每一个HTTP 请求都会有一行Cookie: 123
于是, 这个网站就知道Cookie 为123 的这个用户做了什么, 为这个用户维护一个独立的列表
(如购物车)
当然, Cookie 是把双刃剑, 方便的同时也带有危险性, 例如隐私泄露等, 用户可以自行决定
是否使用Cookie
Session
Cookie 是保存在客户端上的, 而Session 是保存在服务器中. 当服务器收到用户发出的
Cookie 时, 会根据Cookie 中的SessionID 来查找对应的Session, 如没有则会生成一个新的
SessionID 返回给用户
总而言之, Cookie 和Session 就是同一样东西存放地方不同而已.
HTTPS
微信+17031115530，拉测试微信群交流
HTTPS 协议
HTTPS 协议在HTTP 协议的基础上, 在HTTP 和TCP 中间加入了一层SSL/TLS 加密层, 解决了
HTTP 不安全的问题: 冒充, 篡改, 窃听三大风险.
***************************************************************************************************************
关注凡猫学院：加微信+17031115530，拉测试微信群交流
关注凡猫学院：加微信+17031115530，拉测试微信群交流
网友评论