计算机网络-TCP 笔记

《计算机网络(第7版)》
三次握手、四次握手内容整理
TCP和UDP的优缺点及区别

计算机网络常考

http://www.cnblogs.com/zyf-zhaoyafei/p/4716297.html


TCP UDP
是否连接 面向连接 面向非连接
传输可靠性 可靠 不可靠
应用场合 传输大量数据 少量数据
速度

UDP:

  • 仅在ip层之上附加两个服务,即复用分用和对数据的错误检查。
  • 无需维护连接状态,首部8B,开销少
  • 无建立连接时延,执行速度快
  • 无拥塞控制,发送速率稳定,应用层能更好的控制发送数据和发送时间,实时性好
  • 尽最大努力交付,不保证可靠交付,维护传输可靠性交给应用层处理。
  • TFTP(69)、DNS(53)、SNMP(161)
  • 组播广播?

TCP:

  • 实现传输的可靠、有序、无丢失和不重复。
  • TELNET(23)、FTP(21)、SMTP(25)、HTTP
  • 序号确保数据能有序提交给应用层
  • 使用累计确认
  • 超时和冗余ACK会导致重传。每个报文段都有一个计时器;连续3个冗余ACK就重传。

复用:发送方不同的进程可以用同一个传输层协议??ip层不可以吗
分用:接收方能把数据正确的交付给目的进程。(首部有目的端口)
网络层的复用分用
复用:发送方不同协议的数据都可以封装成ip数据包发送出去。
分用:接收方的网络层在剥去首部后能把数据正确的交付给相应的协议。(ip首部有协议字段)


TCP

tcp首部
  • 序号:4B,本报文段所发送的数据的第一个字节的序号。
  • 确认号:4B大小,期望收到对方的下一个报文段的第一个字节的序号,也表示序号到n-1为止的所有数据都已正确收到。(假设ack=n)
  • ACK确认位:ACK=1是确认号才有意义。
  • SYN同步位:SYN=1表示这是一个连接请求(ACK=0)或连接接收(ACK=1)报文。
  • FIN终止位:表明此报文段的发送方的数据已发送完毕并要求释放连接
  • 窗口:大小2B,单位字节,允许对方发送的数据量。
建立tcp连接 三次握手

主动发起连接建立的应用程序叫做客户,被动等待连接建立的应用程序叫做服务器。

  • 第一次握手:客户端请求连接,发送连接请求报文段,不携带数据但是需要消耗一个序号。SYN_SEND,connect(),SYN=1,seq=x

  • 第二次握手:服务器收到连接请求报文段,向客户发送连接接收报文段,同样不携带数据但是需要消耗一个序号;为该tcp连接分配tcp缓存和变量(??为tcp连接分配资源)。SYN_RCVD,SYN=1,seq=y,ACK=1,ack=x+1

  • 第三次握手,客户收到连接接收报文段,还要给服务端发送一个确认报文段。可以不携带数据,不携带就不消耗序号;为该连接分配缓存和变量。ESTABLISHED,ACK=1,ack=y+1,seq=x+1

为什么客户端还要发送一次确认?
主要是为了防止已失效的连接请求报文段(SYN=1,ACK=0)突然出现传给了服务端。
如果没有第三次握手那么服务端发出确认后就是建立连接的状态了,而客户端因为并没有请求连接,所以不会理睬服务端的确认报文段也就不会建立连接,最后服务端维护了一个不会收到数据的连接,浪费了资源。

如果服务器收到其他的确认报文段会怎么处理?

未连接队列
在三次握手协议,服务器维护一个未连接队列,该队列为每个客户端的SYN包seq=x)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于SYN_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。

  • 建立连接时不同的tcp连接不能使用相同的初始序号,为了不使迟到的tcp报文段的序号不处在新的连接所使用的序号范围之中。
  • 服务器在第二次握手时分配资源,客户端在第三次握手时分配资源,这样使得服务器容易受到SYN洪泛攻击(??)

关闭tcp连接 四次挥手
  • 第一次挥手:客户发送连接释放报文段,主动关闭tcp连接,需要消耗掉一个序号。
    FIN-WAIT-1,FIN=1,seq=u

  • 第二次挥手:服务器收到后发出确认报文段。
    CLOSE-WAIT,ACK=1,ack=u+1,seq=v

  • tcp连接此时处于半关闭状态,客户端不发送数据,但服务器发送数据客户端仍要接受。客户收到确认报文段进入FIN-WAIT-2状态,等待服务端发送连接释放报文段。

  • 第三次挥手,服务端没有数据发送后,发出连接释放报文段。
    LAST-ACK,FIN=1,ACK=1,ack=u+1,seq=w

  • 第四次挥手,客户端收到FIN报文端后发送确认报文段。
    TIME-WAIT,ACK=1,ack=w+1,seq=u+1

客户端经过时间等待计时器设置的时间2MSL后,才进入关闭状态。
MSL:最长报文段寿命

为什么客户端在TIME-WAIT状态要等待2MSL才能关闭连接呢?

  • 为了保证最后一个确认报文段能到达服务端,让服务端真的关闭连接。假设这个报文段丢失了,服务端会超时重传FIN报文段,客户端能在2MSL时间内收到这个就会再发送一次确认报文段并重置计时器。如果不等待2MSL的话,客户端已经关闭了连接,接到重传的FIN报文段也不会再发确认报文段,这样服务端就关不了连接了。
  • 防止已失效的连接请求报文段出现在本连接中,等待2MSL可以使本连接产生的所有报文段消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

为什么要有第四次挥手

保活计时器
  • 服务器在连接建立时开启保活计时器(通常时间设置为2小时),是为防客户主机突然故障不能在发送数据,从而浪费服务器连接资源。
  • 每次收到客户数据就重置计时器,若2小时后还未收到数据,就向客户发送探测报文段,以后每隔75秒发一次,如果一连发送10个报文段后客户端还未响应,服务器就认为客户端出了故障,接着关闭连接。
滑动窗口

以字节为单位。
发送窗口拥塞窗口决定发送窗口大小。
全双工通信
接收方有累计确认的功能

  • 发送窗口后沿

    • 不动 没有收到新的确认
      前移 收到新的确认
  • 发送窗口前沿

    • 通常是不断向前移动
  • 发送缓存(发送窗口是它的一部分,后沿重合)

    • 准备发送的数据
      已发送但还未收到确认的数据
  • 接收缓存

    • 按序到达但尚未被读取的数据
      未按序到达的数据
TCP的流量控制

流量控制就是让发送方的发送速率不要太快,要让接收放来得及接收。
利用滑动窗口来实现。
连接建立时,有个窗口协商过程,确认接收窗口大小。即首部的窗口字段,大小2B,单位是字节
B告诉A它的接收窗口是rwnd=400(receiver window)
则A的发送窗口不能超过B接收窗口的值。

A-->B seq=1 A发给B100字节,B还能接收300字节
A-->B seq=101 A发给B300字节,B接收窗口不能再接收新数据了,但能接收超时重传的旧数据
A<--B ACK=1 ack=301 rwnd=200 B表示允许A发送200字节

死锁:B给A发了零窗口的报文段。有空间后B发送窗口=100的报文段给A,但是丢失了。这样A等B的窗口非0的报文段,B又等着A发数据给它。形成死锁的局面。

为解决这个问题,TCP为每个连接设有一个持续计时器。TCP连接的一方收到对方的零窗口通知,就启动计时器。计时器到期就发送一个零窗口探测报文段,接收方确认这个探测报文段时给出了现在的窗口值。如果仍是0,那么重置计时器。如果不是0,那么就破了死锁了。

简单说就是每隔一段时间发送探测报文段确定窗口值。

TCP的拥塞控制

拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。

  • 慢开始、拥塞避免
    基于窗口的拥塞控制。
    发送方让自己的发送窗口等于拥塞窗口。
    只要出现了超时,就认为网络发生了拥塞,发送方减小自己的发送窗口来缓解拥塞。

    1. 慢开始算法:为防一开始就把大量数据注入到网络可能会引起拥塞,所以由小到大逐渐增大发送窗口(即拥塞窗口)。
      每收到一个报文段(重传不算)拥塞窗口就加1,所以每经过一个传输轮次(A全发完拥塞窗口允许的报文段并收到最后一个字段的确认),拥塞窗口就翻倍

    慢开始门限ssthresh
    cwnd<ssthresh 使用慢开始
    cwnd>ssthresh 停止使用慢开始改用拥塞避免

    cwnd=ssthresh 两者都可以

    1. 拥塞避免:让拥塞窗口按线性规律缓慢增长。每经过一个往返时间RTT窗口加1(RTT:发送方连续发送n个报文段并收到n确认的时间)
      加法增大
      超时时,调整门限为cwnd/2并设cwnd=1(乘法减小),进入慢开始阶段。

    2. 快重传:为了让发送方尽早知道发生了个别报文段的丢失。要求接收方收到报文段时立即发送确认。

      • 接收方
        收到M1确认M1;
        收到M2确认M2;
        M3丢失;
        收到M4,重复确认M2;
        收到M5,重复确认M2;
        收到M6,重复确认M2;
      • 发送方
        收到3个连续的对M2的确认,就知道接收方没有收到M3,立即快重传M3。

    发送方收到3个重复ACK,知道是丢失报文段不是拥塞,所以不启动慢开始,而是执行快恢复算法。

    1. 快恢复:调整门限ssthresh=cwnd/2,设置拥塞窗口cwnd=ssthresh,(乘法减小),开始拥塞避免算法。

AIMD算法:加法增大+乘法减小
发送方的窗口上限值是接收方窗口(rwnd)和拥塞窗口(cwnd)两者间的最小值。


ARP:地址解析协议

  1. 每个主机有一个ARP列表,存放ip和对应的mac
  2. 源主机要发送数据时,先检查ARP列表中是否有对应ip的mac,有直接发送,没有就广播一个arp数据包。源ip,源mac,目的ip。
  3. 本网络收到该数据包是,检测ip是否是自己的,不是则忽略,是则将源ip和mac写入列表或者覆盖,然后将自己的mac写入arp响应包中,发给源主机。
  4. 源主机收到,写入arp列表,没有到则arp查询失败。

OSI分层 (7层):物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
TCP/IP分层(4层):网络接口层、 网际层、运输层、 应用层。
五层协议 (5层):物理层、数据链路层、网络层、运输层、 应用层。

每一层的协议如下:
物理层:RJ45、CLOCK、IEEE802.3 (中继器,集线器,网关)
数据链路:PPP、FR、HDLC、VLAN、MAC (网桥,交换机)
网络层:IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 (路由器)
传输层:TCP、UDP、SPX
会话层:NFS、SQL、NETBIOS、RPC
表示层:JPEG、MPEG、ASII
应用层:FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

各种协议

ICMP协议:因特网控制报文协议。它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息。

TFTP协议:是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。

HTTP协议:超文本传输协议,是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。

DHCP协议:动态主机配置协议,是一种让系统得以连接到网络上,并获取所需要的配置参数手段。

NAT协议:网络地址转换属接入广域网(WAN)技术,是一种将私有(保留)地址转化为合法IP地址的转换技术,

DHCP协议:动态主机配置协议(Dynamic host configuration protocol),一个局域网的网络协议,使用UDP协议工作,用途:给内部网络或网络服务供应商自动分配IP地址,给用户或者内部网络管理员作为对所有计算机作中央管理的手段。


《TCP/IP详解卷1》
第10章 用户数据报协议和IP分片

UDP,保留消息边界??的简单的面向数据报的传输层协议,提供差错检测,不提供差错纠正。
不能保证数据正确到达目的地,不可靠;
但是因为无连接特性,比其他协议少很多开销,广播组播更多用udp。
MTU??
主要用途之一是支持DNS。


《计算机网络(第7版)》 谢希仁

OSI七层协议和TCP/IP四层协议结合来的。

  • 应用层:
    应用进程通信和交互的规则。
    域名系统DNS、支持万维网应用的HTTP协议、支持电子邮件的SMTP协议等。
    报文
  • 运输层:
    向两台主机中进程之间的通信提供通用的数据传输服务。
    复用,多个进程可同时使用下面运输层的服务;
    分用,运输层把收到的信息分别交付上面应用层中的相应进程。
    传输控制协议TCP,提供面向连接的可靠的数据传输服务,报文段;
    用户数据报协议UDP,无连接的,不可靠的数据传输服务,用户数据报。
  • 网络层:
    负责为不同主机提供通信服务,把报文段或用户数据报封装成分组或包进行传送;
    选择合适的路由,使分组能够通过网络中的路由器找到目的主机。
    网际协议IP,数据报;
    多种路由选择协议
  • 数据链路层:
    将ip数据报组装成帧,在两个相邻结点间的链路上传送,数据和必要的控制信息?。
    控制信息能使接收端知道一个帧从那个比特开始和到哪个比特结束;检错;纠错(需要可靠传输协议)
  • 物理层:

CSRF:跨站请求伪造。防止:可判断请求来源(referer)是否本站点,或者加校验码
XSS:跨域脚本攻击。

http1、http1.1、http2的区别
·

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,921评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,635评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,393评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,836评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,833评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,685评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,043评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,694评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,671评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,670评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,779评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,424评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,027评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,984评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,214评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,108评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,517评论 2 343

推荐阅读更多精彩内容