TCP协议中的流量控制和拥塞控制研究毕业论文


    




    毕业设计 ( 文)

    TCP协议中流量控制拥塞控制研究




    数学统计学院
    专业名称
    信息计算科学
    班级学号

    学生姓名

    指导教师


    年 月 日
    TCP协议中流量控制拥塞控制研究

    计算机网络技术发展迅速计算机技术保证网络稳定运行关键计算机网络协议TCP协议作网络协议中核心协议重性更言喻该协议研究完善促进网络发展重手段
    着互联网规模互联网应快速增长网络拥塞数突问题已引起密切关注拥塞控制流量控制技术针网络中拥塞数突成网络领域核心技术中流量控制象接收端目发送端发送速率超接收端接收力拥塞控制象网络环境目负载超网络传送力
    TCP流量控制赖滑动窗口通流量约束减少接收端出数流失提高发送效率充分利接收端资源
    TCP拥塞控制原理赖拥塞窗口(cwnd)控制窗口值代表够发送出没收ACK数报文段显然窗口越数发送速度越快越网络出现拥塞果窗口值1简化停等协议发送数等方确认发送第二数包显然数传输效率低TCP拥塞控制算法两者间权衡选取cwnd值网络吞吐量化产生拥塞
    文首先TCP协议发展做简概述然分析TCP协议报文段格式结构TCP数传输程接着讨TCP流量控制机制针TCP重点部分拥塞控制进行分析讨TCP拥塞控制算法

    关键词:TCP协议流量控制拥塞控制
    The Flow Contral and Congestion Control in TCP Protocol
    Abstract
    Computer network technology is one of the most rapidly developing of computer technology todayand the computer network protocols is the key to ensure the network is stable and re
    liable operation TCP protocol as one of the core protocols of the network protocolis vary important so to research and improve the protocol is one of the important means to promote the development of the network
    With the rapid growth of Internet scale and the Internet application network congestion and data conflict problem has aroused the concern of the people closely Congestion control and flow control technology according to the theory of network congestion and data conflict has become the core technology in the field of network The flow control object is the receiver the purpose is to make the sending rate does not exceed the capacity at the receiving end Congestion control object is the network environment the purpose is to make the transfer of a loaded with no more than the network capacity
    TCP flow control is mainly depended on the sliding window by flow constraints and reduce the loss of data at the receiving end to improve the transmission efficiency make full use of the receiver
    The main principle of TCP congestion control relies on a congestion window (cwnd) to control the window size value represents the ability to send out but not yet received the maximum data packet ACK Duan clear window so the greater the speed of data sent the faster but also more likely to make the network congestion occurs if the window is 1 then reduced to a stop such agreement each sending a data must wait for confirmation of the other party can send a second packet the data clearly transmission efficiency is low TCP congestion control algorithm is to balance between these two choose the best cwnd value allowing the network to maximize throughput and does not create congestion
    Firstly the development of the TCP protocol a brief overview and then analyzed the structure of TCP protocol TCP data transfer process followed by a discussion of the TCP flow control mechanism the key part of the final for the TCP congestion control are analyzed discussed Several TCP congestion control algorithm

    Key Words TCP protocol Flow controlCongestion control
    目 录
    1 绪 1
    11 TCP发展程设计目标 1
    111 TCP发展程 1
    112 TCP设计目标 1
    12 文结构 2
    2 TCP协议 3
    21 TCP报文段 4
    211 TCP报文格式 4
    212 TCP报文封装 5
    22 TCP数传输 6
    221 TCP连接建立 6
    222 TCP连接释放 7
    3 TCP协议中流量控制 8
    31 滑动窗口 8
    32 变窗口流量控制实例分析 8
    4 TCP拥塞控制 10
    41 拥塞产生原 10
    42 重发定时器理 11
    421 RTT估算 12
    422 RTO计算 12
    43 TCP 拥塞控制采机制 13
    5 TCP拥塞控制算法 17
    51 TCP 早期实现 17
    52 TCP Tahoe 17
    53 TCP Reno算法 17
    54 TCP NewReno 18
    55 TCP SACK 19
    56 TCP Vegas 20
    结 22
    致 谢 23
    参考文献 24
    附 录 25

    1 绪
    计算机网络计算机通信密切结合产物年迅速发展已逐渐成信息社会基石网络协议计算机中缺少重组成部分计算机计算机间计算机设备间进行数通信必条件TCP协议作重网络协议发展
    11 TCP发展程设计目标
    认识源实践认识终目标正服务实践解TCP发展历史相应设计目标TCP拥较全面认识更研究TCP技术满足越越高应需求
    111 TCP发展程
    互联网初源美国国防部ARPANET计划世纪60年代中期正冷战高峰美国国防部希命令控制网络确保核战争条件幸免难传统基电路交换电话网络脆弱国防部指定属高级研究计划局解决问题诞生ARPANET特点采连接端端报文交换服务80年代中期演变互联网TCP协议初作NSFNET程序规范RFC 793早较完整齐全TCP规范规范简单描述进行机机传输描述传输控制协议执行功相应实现程序程序接口TCP协议设计初赋予高命需成报文交换计算机网络网络互联系统中高性传输协议需明确网络中传输包括两方面:首先数正确前传输介质质量差传输层层协议中实现校验计算次数完整保序特性需TCP执行复杂操作实现通常强调TCP传输时指者
    112 TCP设计目标
    TCP设计初网络技术刚刚起步相应硬件设施达低水应需求十分简单诸素导致TCP协议设计目标开始已先天足设计TCP协议时网络尤型互联网络缺乏质认识遗漏许TCP协议应该具备重特征例现熟知拥塞控制初协议设计中没体现
    TCP初设计目标进程间提供安全逻辑链路基础提供传输服务需强调TCP网络做假设功提供逻辑链路够网络进行通信协议必须提供功:够进行基数传输保证数性进行适流量控制维护通信状态集合行路技术保证通信优先级 安全性
    12 文结构
    文围绕列问题展开研究:
    1.TCP结构数传输程
    2.TCP流量控制机制
    3.TCP拥塞控制拥塞控制算法
    2 TCP协议
    TCP 协议目前互联网应广泛传输层协议提供端端字节流传送服务
    TCP 面连接协议端系统进行数传输前建立连接连接属全双工方式(数两方时进行传输)TCP IP 网络层提供数传输服务传输数终应达接收端TCP 中接收端接收分组进行确认定时间范围没确认分组会发送方重新进行发送接收端果收重复分组会丢弃该分组果收乱序分组分组进行重新排序分组会应序列号发送方通分组确认报文获接收端希接收分组序列号通信双方均数发送时TCP 确认信息放数分组中发送减少控制信息带额外流量TCP协议数单元传输重传策略网络拥塞状况着深刻影响
    概括说TCP 协议应层提供服务:
    1.流交付服务TCP 协议允许发送进程字节流形式传递数接收进程数作字节流接收样TCP 协议两进程假想道中传送两进程数
    2.全双工服务数时间双流动TCP 端系统发送缓存接收缓存两方发送报文段
    3.面连接服务TCP 通条虚拟连接传送数TCP 报文封装成IP 分组分组走路径达目端收IP 分组会乱序会丢失者受损伤重传TCP 创建面流环境负责序完整数交付应程序
    4.流量控制流量控制定义发送端收接收端发确认前发送数量TCP 协议缓存定义窗口缓存暂时存放应程序传递准备发送数TCP 发送端根窗口发送数谓滑动窗口机制
    5.差错控制TCP 传输层协议表示应程序数流交付IP 层TCP协议应数流序没差错没损伤交付应程序实现差错控制TCP 协议采种机制:检测受损伤丢失失序重复数包检测差错够纠正差错
    6.拥塞控制互联网许网络连接设备组成发送端发送分组路器达接收端路器保证链路利率般会提供缓存暂时存储突发达分组路器接收分组时导致路器缓区溢出该路器节点发生拥塞部分分组会丢弃发送端重传分组时会造成更加严重拥塞致网络瘫痪必须端系统采拥塞控制机制保证网络会发生拥塞时充分利网络链路资源TCP协议采慢启动拥塞避免等算法网络拥塞进行控制定程度保证网络稳定运行
    21 TCP报文段
    211 TCP报文格式
    TCP 软件两台计算机间传输数单元称报文段(segment)通报文段交互建立连接传输数发出确认通告窗口关闭连接图21表示出TCP 报文段格式报文段分两部分:首部数报文段建立连接运载数应答
    TCP源端口号(16位)
    TCP目标端口号(16位)
    序列号(32位)
    确认序列号(32位)
    首部长度(4位)
    保留
    (6位)
    URG
    ACK
    PSH
    RST
    SYN
    FIN
    窗口(16位)

    校验(16位)
    紧急指针(16位)
    选项填充
    数区
    图21 TCP报文段格式
    TCP报文段首部固定部分字段意义:
    源端口目端口:占2字节传输层高层接口
    序列号:占4字节报文段发送数部分第字节序号TCP输送数流中字节序号例报文段中序号300报文中数100字节报文段中序号400见TCP面数流
    确认序列号:占4字节期收方次发送数第字节序号
    首部长度:占4bit指出32bit 单位TCP 报文段首部长度首部字段面6bit保留字段应保留目前置0
    紧急特URG:URG 1时表明报文段应该快发送原排队序发送通常紧急指针(位第532bit 字段中半)配合紧急指针指出报文段中紧急数字节序号紧急指针接收方知道紧急数长需注意窗口0时发送紧急数
    确认特ACK:ACK 1时确认序号字段意义ACK 0时确认序号意义
    急迫特PSH:PSH 1时表明请求远TCP报文段立传送应层等整缓区填满交付
    复位特RST:RST 1时表明出现严重差错必须释放连接然重新建立连接
    步特SYN:连接建立时SYN 1ACK 0时表明连接请求报文段方意建立连接应发回报文段中SYN 1ACK 1SYN置1表示连接请求连接接受报文ACK 特值区分种报文
    终止特FIN:释放连接FIN 1时表明欲发送字节串已发完请求释放传输层连接
    窗口:占2字节窗口字段提供端端流量控制表示确认字节发送少字节字段值0合法表示已收包括确认号减1(发送报文段
    )报文段前接收方急需暂停通发送带相确认号滑动窗口字段非零值报文段恢复原传输
    校验:占2字节校验字段覆盖范围包括首部数概念伪TCP首部
    选项填充:占2字节选部分TCP具体选项填充作确保首部32位整倍数
    212 TCP报文封装
    图22示TCP报文段封装IP数报中然封装成数链路层中帧通物理层传输数接收端接受端数链路层剥帧首部然送接收端网络层剥IP首部发送传输层剩发送段TCP报文段
    IP首部
    TCP首部
    TCP数

    IP报文段
    TCP报文段

    图22 报文段封装
    22 TCP数传输
    221 TCP连接建立
    TCP全双工方式传输数两机器重两TCP建立连接候够时方发送报文段表示数传输前方必须通信进行初始化方认TCP连接TCP连接建立称三次握手1客户发送第报文段SYN报文段报文段中SYN标志置1报文段作序号步客户端选择机数SEQ作第序号序号发服务器2服务器发送第二报文段SYN+ACK报文段中两标志置l报文段两目SYN步初始序号服务器ACK标志确认已客户端收SYN报文段时出期客户端收序号3客户端发送第三报文段仅仅ACK报文段ACK标志确认号字段确认收第二报文
    实例分析:
    SYN 1SEQ 800
    SYN1ACK1SEQ1500ACK801
    ACK 1SEQ 1501ACK 801

    机A
    机B
    连接请求

    图23 TCP连接建立
    面机A机B两应程序例分析图23示程服务器开始机A告诉TCP已准备接受连接做动开机B发送请求做动开ATCPBTCP发出连接请求报文段首部中特SYN应置1时选择序号X选取X 800表明面传输数第数字节序号X+1801BTCP收连接请求报文段意发回确认确认报文段中SYNACK置1确认号X+1801时选择序号Y令Y 1500ATCP收B确认B出确认ACK置1确认号Y+11501序号X+1801
    222 TCP连接释放
    参加交换数双方方关闭连接方连接终止时方继续方发送数建立连接需三次握手终止连接四次握手
    FIN 1SEQ 1001
    ACK 1SEQ 1700ACK 1002
    FIN1ACK1SEQ1700ACK1002

    机A
    机B
    释放链接
    ACK 1SEQ 1002ACK 1701
     
    确认
    确认

    图24 TCP连接释放
    实例分析:
    图24示机A应进程先TCP发送连接释放请求发送数TCP通知方释放AB方连接发机BTCP报文段首部FIN置1序号X等前面已传送数字节序号加1X 1001机BTCP收释放链接通知发出确认序号Y 1700确认号X+11002时通知高层应进程应进程通知TCP释放连接B发出连接释放报文段必需FINACK置1序号Y重复次发送ACK X+1A确认ACK置1ACKY+1 1701序号X+11002
    3 TCP协议中流量控制
    果发送端发送数者数发送速率快致接收端处理会造成数接收端丢弃避免种现象发生通常处理办法采流量控制控制发送端发送数量数发送速率时期超接收端承受力力指接收端缓存数处理速度
    流量控制点点通信量关针端系统中资源受限设置解决快速发送方慢速接收方问题流量控制目限接收端承受力情况通流量约束减少接收端出数丢失提高数发送效率充分利接收端资源
    31 滑动窗口
    TCP特点提供体积变滑动窗口机制支持端端流量控制TCP窗口字节单位进行调整适应接收方处理力处理程:首先TCP连接阶段双方协商窗口尺寸时接收方预留数缓区次发送方根协商结果发送符合窗口尺寸数字节流等方确认发送方根确认信息改变窗口尺寸
    1 100
    101 200
    201 300
    301 400
    401 500
    501 600

    发送窗口
    已发送确认
    已发送未确认
    继续发送
    发送
    指针

    图31 滑动窗口
    图31表示发送窗口400字节发送端已发送300字节数收前100字节确认时窗口变现发送端发送200字节
    32 变窗口流量控制实例分析
    设机A机B发送数图32示双方规定窗口值400设报文段100字节长序号初始值1机B进行3次流量控制第次窗口减少300字节第二次减200字节次减08字节允许发送数

    SEQ 1
    SEQ 101
    SEQ 201丢失
    ACK201WIN300
    SEQ 301
    SEQ 401
    SEQ 201
    ACK501WIN200
    SEQ 501
    ACK 601WIN 0
    A发送200字节
    A发送200字节
    丢失序号201—300数
    允许A发送300字节(序号201—500数)
    A发送200字节(序号301—500数)
    A发送100字节(序号401—500数)
    A超时重发(201—301字节数)
    允许A发送200字节
    A发送100字节(序号501—700数)
    序号600前数收允许A发送
    机A
    机B

    图32 变窗口流量控制
    4 TCP拥塞控制
    拥塞种持续载网络状态时户网络资源(缓存空间链路带宽容量中间节点处理力等)需求超固容量网络性
    (功率返时间RTT吞吐量)负荷关系图41说明出负荷较时网络吞吐量资源功率(资源功率=吞吐量响应时间)负荷增长指数增长RTT负荷增长略升负荷达膝点时功率达值吞吐量增长远远慢负荷增长RTT迅速升功率快速降继续增长负荷存丢包负荷达崖点时吞吐量达值功率达值RTT指数增长系统处拥塞状态膝点指资源功率达值负荷量崖点指资源功率降值开始丢包时负荷量膝点理想工作点拥塞控制采某种策略机制保持网络工作正常状态网络常工作崖点左侧区域种控制机制网络工作膝点附该方法称拥塞避免种控制机制网络工作崖点崖点网络回复膝点前该方法称拥塞恢复

    图41 网络性负荷间关系
    41 拥塞产生原
    着通信计算机技术成熟发展互联网规模增长网络户网络应快速增长包括话音文字数图等种媒体通信需求断增计算机网络中许网络资源链路容量交换节点中缓区处理机等果某段时间户(端系统)加网络负载网络资源容量处理力会产生拥塞网络性变坏网络中许资源时产生拥塞网络性明显变差整网络吞吐量输入负载增降表现数包时延增加丢弃概率增层应系统性降等
    总说资源紧缺资源合理利时产生拥塞控制直接原具体表现:
    1.存储空间足:输入数流需输出端口端口会建立排队果没足够存储空间存储数包会丢弃突发数流更增加存储空间某种程度缓解矛盾果路器限存储量时拥塞会交更坏更网络里数包长时间排队完成转发时早超时源端认已丢弃数包会继续路器转发浪费网络资源加重网络拥塞
    2.带宽容量足:低速链路高速数流输入会产生拥塞根香农信息理信道带宽值信道容量 (N信道白噪声均功率S信源均功率B信道带宽)信源发送速率R必须等信道容量C果R>C理差错传输网络低速链路处会形成带宽瓶颈满足通源端带宽求时网络会发生拥塞
    3.处理器处理力弱速度慢引起拥塞:避免拥塞发生原需综台考虑拥塞然网络资源稀缺引起单纯增加资源避免拥塞发生定程度时会加重拥塞减轻拥塞报文段长时间排队完成转发时早超时引起源端超时重发报文段会继续传输路器浪费网络资源加重网络拥塞事实缓存空间足导致丢包更拥塞症状非原外增加链路带宽提高处理力解决拥塞问题
    单纯增加网络资源解决拥塞问题拥塞身动态问题静态方案解决需网络协议网络出现拥塞时保护网络正常运行需网络拥塞进行控制
    拥塞旦发生会形成断加重程加控制会影响网络性严重情况甚会整网络发生瘫痪拥塞控制网络中必少机制
    42 重发定时器理
    重发定时器理TCP拥塞控制中关键技术
    TCP发送报文段设置次计数器计时器设置重传时间没收确认重传报文段重传时间间隔取值(RTO)直接影响发送端网络反应情况取值太会造成必重传浪费网络资源:取值太报文段丢失反应会迟缓RTO值RTT(Round Trip Time)关系正确估算RTT值合理选择RTO值TCP性重影响
    421 RTT估算
    整端端路径返时间RTT(Round Trip Time)指源端发出报文段收相应确认间时间间隔RTT 包括正反路径中跳链路时延(传输时延物理传播时延)中间结点处理时延(排队路查找转发)RTT 着中间结点排队情况表现出定机性果中间结点较长队列RTT 变化会种计算RTT 方法观察报文段返时间简单取均通常希更期采样值予更权值更反映行常_种技术指数均法滑RTT 值计算:

    中SRTT(K)前K报文段滑返时间估值:α指数均权值(0<α<1)α 越予更迸观察值权值越通常α取值78时权重10左右观察值
    422 RTO计算
    RTO计算三种方法RTT方差估计(Jacobson算法)指数RTO退避Karn算法
    1.RTT方差估计: 初TCP规约试图通RTT估值常数子B(通常取B2)方法确定RTO值稳定环境中RTT方差低述方法RTO必取太高稳定环境中p取值2足防止必重传RTT方差估计通滑RTT方差倍数滑返时间确定定时器取值更效计算RTO值完整算法表达:
    采样滑偏差:
    滑偏差:
    重发定时器:
    般情况h取值14ƒ取值4
    验证明算法显著提高TCP性
    2.指数RTO 退避:果TCP发送端报文段发生超时必须重传报文段考虑超时网络拥塞引起网络足够时间拥塞中恢复更明智策略TCP源端报文段重传时增加RTO称退避程
    (backoff process)实现RTO退避种简单方法报文段次重传RTO常数值 RTO次重传指数增长q通常取2时称二进制指数退避(binary exponential backoff)
    3.Karn 算法:假定报文段发生超时必须重传果收—确认两种:
    1)报文段第次传输ACK种情况RTT 仅期更长网络状况精确反映
    2)第二次传输ACK
    TCP源端没办法区分两种情况果发生第二种情况TCP实体简单RTT算成第次传输收ACK段时间时间实际RTT长错误RTT输入Jacobson算法中会产生太高SRTTRTO外效果会前传播许次迭代次迭代产生SRTT值次迭代输入值
    种更糟方法RTT算成第二次传输收ACK段时间果ACK实际第次传输ACK测RTT值实际值许导致SRTTRTO值太产生正反馈效应引起更重传更错误测量
    Karn算法采规解决问题:
    1)重传报文段测RTT更新SRTTSDEV
    2)重传时等式计算退避RTO
    3)续报文段退避RTO值直收未重传报文段确认止未重传报文段确认收Jacobson算法激活计算RTO值
    43 TCP 拥塞控制采机制
    更进行拥塞控制TCP采四种机制:慢启动拥塞避免快速重传快速恢复
    1.慢启动:
    连接刚建立超时时进入慢启动阶段新建TCP连接时拥塞窗口初始化数包源端cwnd发送数收ACK确认增加数包发送量样慢启动阶段cwndRTT呈指数级增长
    慢启动采逐渐增cwnd方法防止TCP启动连接时网络发送数包造成必数丢失网络拥塞够避免采单纯AIMD算法造成吞吐量增加慢问题
    防止cwnd限制增长引起网络拥塞引入状态变量:慢启动门限值ssthresh
    cwndcwnd>ssthresh时拥塞避免算法减缓cwnd增长速度
    cwndssthresh时慢启动算法拥塞避免算法
    2.拥塞避免:
    发现超时收3相ACK确认帧时网络发生拥塞(传输引起数包损坏丢失概率(ssthreshTCP执行拥塞避免算法时cwnd次收ACK时增加1/cwnd数包样RTTcwnd增加1拥塞避免阶段cwnd呈指数增长线性增长
    3.快速重传快恢复阶段:
    拥塞避免阶段数包超时时cwnd置1重新进入慢启动阶段会导致减发送窗口尺寸降低TCP连接吞吐量引入快速重传快速恢复机制
    快速重传阶段源端收33重复ACK时判定数包丢失应该立刻重传进入快速恢复阶段
    快速恢复阶段设置ssthreshcwnd2重传丢失报文段设置cwndssthersh+n(n已收重复报文段数)收非重复ACK时置cwnd=ssthresh转入拥塞避免阶段果发生超时重传置ssthresh前cwnd半cwnd=1重新进入慢启动阶段种方法避免数包超时重新进入慢启动阶段提高TCP连接吞吐量
    实例分析:
    面通实例分析TCP拥塞控制阶段
    1.慢启动拥塞避免实例
    先假设窗口单位报文段TCP连接进行初始化时拥塞窗口置1cwnd1慢开始门限初始值设置8ssthresh8发送端发送窗口win超拥塞窗口cwnd通告窗口awin中值假定通告窗口awin足够发送窗口win数值等拥塞窗口cwnd数值执行慢启动算法时拥塞窗口cwnd1发送端收新报文段确认ACKcwnd+1开始次传输cwnd增长慢开始门限值ssthresh时cwnd8时改拥塞避免算法假定拥塞窗口数值增长12时网络出现超时更新ssthresh6拥塞控制窗口cwnd1执行慢启动算法cwnd6时改拥塞避免算法
    16

    12

    8


    4



    0 2 4 6 8 10 12 14 16 18
    ssthress8
    更新ssthress6
    控制窗口cwnd
    传输次数
    进入拥塞避免
    进入拥塞避免
    超时

    图42慢启动拥塞控制实例
    图42中发送3次收3ACK控制窗口cwnd达慢开始门限值ssthresh8进入拥塞避免阶段传输4次cwnd12时网络发生拥塞执行拥塞避免算法cwnd1ssthresh6开始慢启动阶段cwnd6时进入拥塞避免阶段
    2.快重传快恢复实例
    假定发送端发送A1—A44报文段接收端收A1A2A3发出确认ACK2ACK3ACK4网络拥塞A4丢失接收端收A5发现序号收放缓存中时发出确认ACK4发送端接着发送A5A6接收端收分发送重复ACK4样发送端收4ACK4中3重复发送端断定分组丢失立重传A4时进入快恢复阶段设置ssthreshssthresh2cwndssthresh+3果发送继续发送A7收新报文段ACK8设置
    cwndssthresh
    16

    12

    8


    4



    0 2 4 6 8 10 12 14 16 18
    ssthress8
    更新ssthress6
    控制窗口cwnd
    传输次数
    进入拥塞避免
    收新报文段ACK
    收3重复ACK快速重传
    快速恢复

    图43 快重传快恢复实例
    图43cwnd12时收3重复ACK发送方断定分组丢失开始重传进入快速恢复阶段ssthreshcwnd26cwndssthresh+39次传输收新报文段确认ACKcwnd设置cwndssthresh进入拥塞避免阶段
    5 TCP拥塞控制算法
    TCP协议年发展种具体实现TCP第实现现断改进现TCP拥塞控制算法TahoeRenoNewRenoSACKVegas中TahoeRenoNewRenoSACK基AIMD(Additive Increase Multiplicative Decrease)机制改变拥塞窗口cwndVegas通观察前TCP连接中RTT值改变情况控制cwnd
    51 TCP 早期实现
    早期TCP简单停止等协议发送报文等确认序发送报文效率低等确认网络资源充分利外必须等重传计时器超时重新发送丢失报文网络拥塞未采取效措施
    52 TCP Tahoe
    1988年Jacobsen改进原TCP机制提出Tahoe算法早期实现基础Tahoe加入慢启动拥塞避免快速重传机制重发定时器取值进行改进具
    RTT估计差错恢复功Tahoe基思想探测网络带宽拥塞时急剧降低数发送速率 (:丢失报文段重传cwnd值降1ssthresh置cwnd2重新进入慢启动阶段)
    Tahoe算法存着足处:收3重复ACK超时情况Tahoe置cwnd1然进入慢启动阶段方面会引起网络激烈振荡方面降低网络利率
    53 TCP Reno算法
    针Tahoe算法足处1990年JacobsonTahoe基础提出改进算法Reno改进两方面:收连续3重复ACK算法慢启动直接进入拥塞避免阶段二增加快速重传快速恢复机制具体实现程:
    1.收三重复ACK进入快速重传快速恢复时ssthresh设置前拥塞窗口半
    2.重传丢失数包置cwnd=cwnd+n (n收重复ACK数)
    3.发送新数包
    4.收非重复ACK时cwnd=ssthresh
    5.进入拥塞避免阶段
    面程出Reno收3重复ACK转入快速重传快速恢复阶段遇超时时RenoTahoe样进入慢启动阶段
    果发送窗口包丢失时该算法效恢复出
    54 TCP NewReno
    1996年Reno基础提出NewReno算法Reno快速恢复机制进行改进避免窗口发生报文段丢失情况传输性降Reno中发送端收重传报文段确认结束快速恢复程NewReno收该窗口报文段确认退出快速恢复程避免出现丢失造成cwnd连续减NewRenoReno更保证网络稳定性
    NewRenoReno仅步骤1(面述)中变量recover引入步骤5中收部分新确认ACK处理方式NewReno中定义快速恢复程快速重传快速恢复机制概括五步:
    1.TCP发送端收第三重复ACK发送端没处快速恢复阶段时式设置ssthresh值然变量recover记录时传送序列号

    2. TCP发送端重传丢失报文段设置cwnd值:cwndssthresh+3×MSS已离开网络报文段数目接收端已缓数量扩充拥塞窗口
    3.次接收额外重复ACKcwnd增MSS字节扩充拥塞窗口反映已离开网络报文段
    4.果cwnd接收端通告窗口值允许话TCP发送端发送报文段
    5.确认新报文段ACK达时(ACK步骤2中重传引发确认者稍次重传引起):
    果ACK确认直包含序列号recover报文段ACK确认TCP发送端丢失报文段第次传送第三重复ACK接收间发送报文段TCP发送方设置cwnd值:

    处ssthresh步骤1中值(步骤l中发送窗口TCP进入快速恢复阶段时值:步骤5中发送窗口TCP退出快速恢复阶段时值)
    果ACK包含序列号recover报文段确认ACK部分确认种情况TCP发送端退出快速恢复程立重传部分确认ACK中指示第没确认报文段Reno处理部分确认方式Reno收部分确认ACK立退出快速恢复程果重复ACK达NewReno发送端重复执行面步骤34发送窗口中报文段丢失时NewReno需等超时重发定时器超时报文段丢失中恢复TCP发送端返时间重发丢失报文段直重发丢失报文段止NewReno直处快速恢复阶段直发送端进入快速恢复前发出报文段确认止
    55 TCP SACK
    1996年提出Reno改进SACK算法利SACK报文段中选项接收报文进行确认根SACK选项确认信息发送端确知报文段已接收重传实际丢失报文段利发送端单窗口丢失报文段环境中快速恢复
    SACK两种TCP选项:授权选项SACK选项
    授权选项连接建立时选项包含SYN报文中发送表示连接SACK 选项占两字节格式:
    Kind4
    Length2
    典型SACK算法Reno算法种简单改进扩减拥塞窗口相机制TCP中增加SACK改变拥塞控制基机制SACK实现TahoeReno报文段失序时健壮性必时然重发定时器超时重发机制进行恢复
    SACKReno差报文段数发送窗口丢失时采取策SACKReno样般TCP发送端收3重复ACK时进入快速恢复阶段发送端重发传输程重丢失报文段拥塞窗口减半SACK快速恢复算法中SACK保持变量pipe表示前传输路径报文段估计数量点SACKReno实现机制pipe拥塞窗口时发送端发送新已重发数发送端发送新报文段重发老报文段时pipe值增l发送端接收带SACK选项重复AEK时表明新数接收者接收pipe值减1pipe变量时发送报文段发送报文段分离开
    果重发报文段丢失SACK重发定时器超时察觉重发丢失报文段然进入慢启动阶段收恢复ACK确认进入快速恢复时出现数发送端退出快速恢复阶段外SACK发送端快速恢复阶段收恢复ACK特殊处理方法:ACK发送端pipe变量值次减2减l
    56 TCP Vegas
    1994年提出Vegas算法前种算法Vegas种通检测网络流量避免拥塞拥塞控制算法Vegas策略调整信源发送速率传输路径路器中缓存少量分组三方面TEP拥塞控制基机制进行改进重传机制拥塞避免机制慢启动机制
    1.新重传机制:
    VegasReno重传机制做扩充:首先Vegas读取记录次报文段发送时系统时钟
    ACK达时Vegas次读取时钟时间相应报文段记录时间戳计算RTT值然Vegas更精确RTT估值决定面两种情况重传:收重复ACK时Vegas检测前时间相应报文段发送时间差值否超时值超时值发送端重传报文需等收三重复ACK做出反应更时做出反应时避免进入样种状态:发送端永远收三重复ACK赖定时器超时进行重发
    收非重复ACK时果重传收第第二确认Vegas次检测报文段发送时间间隔否超时值超时值重传报文段样会知道早先重传前丢失报文段需等第重复ACK达觉察
    2.改进拥塞避免机制:
    Vegas目标保持网络中恰数量额外数显然果连接发送额外数会导致拥塞果连接发送少额外数带宽条件快速增加Vegas拥塞避免基网络中额外数估计量变化基丢失报文现象具体实现:
    定义期(expected)实际(actual)吞吐量期吞吐量代表没现网络拥塞情况连接带宽实际吞吐量代表连接前带宽收ACK发送端1式计算期实际吞吐量间差值diff:

    中basertt测RTT值:artt均测RTT值Vegas定义两阈值α(触发窗口增加)β(触发窗口减)目发送端RTT效控制diff值
    便实际吞吐量接期吞吐量阶段拥塞窗口变化式决定

    Vegas通方法控制网络出现拥塞减丢失率
    3.改进慢启动机制:
    慢启动阶段检测避免拥塞Vegas做改进:采种更谨慎方法增加窗口条链路建立时两RTT窗口指数增加两
    RTT间cwnd保持变实际期速率进行效较实际速率期少缓存时Vegas慢启动模式变线性增加减模式改进效减少慢启动阶段报文段丢失发生

    综述TCP协议安全传输特性网络发展中占重位置研究必着高速网络发展线线等种网络混合传统TCP协议已显示出少弊端新型网络时代中改进迫眉睫尤拥塞控制算法改进提高TCP性帮助
    着网络技术断发展网络传输速率传输量断增加TCP未趋势出延时测量TCP性产生越越影响通硬件加速提高协议性值研究方面
    致 谢
    参考文献
    附 录
    译文1 Simulationbased Comparisons of Tahoe Reno and SACK TCP
    Kevin Fall and Sally Floyd
    In this paper we illustrate some of the benefits of adding selective acknowledgment (SACK) to TCP Current implementations of TCP use an acknowledgment number field that contains a cumulative acknowledgment indicating the TCP receiver has received all of the data up to the indicated byte A selective acknowledgment option allows receivers to additionally report nonsequential data they have received When coupled with a selective retransmission policy implemented in TCP senders This work was supported by the Director office of Energy Research Scientific Computing Staff of the US Department of Energy under considerable savings can be achieved Several transport protocols have provided for selective acknowledgment (SACK) of received data These include NETBLT XTP RDP and VMTP The first proposals for adding SACK to TCP were later removed from the TCP RFCs
    (Request For Comments) pending further research The current proposal for adding SACK to TCP is given in [MMFR96] We use simulations to show how the SACK option define in [MMFR96] can be of substantial benefits relative to TCP without SACK
    Without SACK Reno TCP has performance problems when multiple packets are dropped from one window of data These problems result from the need to await a retransmission timer expiration before reinitiating data flow Situations in which this problem occurs are illustrated later in this paper
    Not all of Reno's performance problems are a necessary consequence of the absence of SACK To show why we implemented a variant of the Reno algorithms in our simulator called NewReno Using a suggestion from Janey Hoe NewReno avoids many of the retransmit timeouts of Reno without requiring SACK Nevertheless NewReno does not perform as well as TCP with SACK when a large number of packets are dropped from a window of data The purpose of our discussion of NewReno is to clarify the fundamental limitations of the absence of SACK In the absence of SACK both Reno and NewReno senders can retransmit at most one dropped packet per roundtrip time even if senders recover from multiple drops in a window of data without waiting for a retransmit timeout This characteristic is not shared by Tahoe TCP which is not limited to retransmitting at most one dropped packet per roundtrip time However it is a fundamental consequence of the absence of SACK that the sender has to choose between the following strategies to recover from lost data
    1 retransmitting at most one dropped packet per roundtrip time or
    2 retransmitting packets that might have already been successfully delivered
    To illustrate the advantages of TCP with SACK we show simulations with SACK TCP using the SACK implementation in our simulator SACK TCP is based on a conservative extension of the Reno congestion control algorithms with the addition of selective acknowledgments and selective retransmission With SACK a sender has a better idea of exactly which packets have been successfully delivered as compared with comparable protocols lacking SACK Given such information a sender can avoid unnecessary delays and retransmissions resulting in improved throughput We believe the addition of SACK to TCP is one of the most important changes that should be made to TCP at this time to improve its performance
    In Sections 2 through 5 we describe the congestion control and packet retransmission algorithms in Tahoe Reno NewReno and SACK TCP Section 6 shows simulations with Tahoe Reno NewReno and SACK TCP i
    n scenarios ranging from one to four packets dropped from a window of data Section 7 shows a trace of Reno TCP taken from actual Internet traffic showing that the performance problems of Reno without SACK are of more than theoretical interest Finally Section 8 discusses possible future directions for TCP with selective acknowledgments and Section 9 gives conclusions

    基重传TCP仿真介绍
    篇文中介绍选择重发(sack)选项TCP协议益处拥塞控制算法般分两类:基窗口基位率拥塞控制算法基窗口控制算法通源端限制数报传送应答种机制源端需发送数进行整形优点易实现限制量数量造成良影响进行控制然基位率控制算法发送流量进行整形防止爆发数流出现种算法优点果源端传输率网络匹配缩减交换机需缓存区
    许传输协议提供选择重传选项中描述TCP快速恢复算法典型实现TCP数发送端发生超时重传时仅仅重传数包者三重复确认达时触发快速重传算法单单超时重传导致许 数包重传次Reno快速重传算法启仅仅导致数包重传 数包数窗口中丢失触发快速重传快速恢复算法时问题 会产生种情况果SACK选项TCP发送端快速恢复期间足够信 息决定重传数包重传数包篇文档仅TCP选择确认(SACK) 选项TCP连接适 没SACK情况TCP发送端快速恢复期间少信息作出重传决 定三重复确认中发送端推断出数包丢失重传声明数包 数发送端接收外重复确认发送端进入快速重传时数端确 认已发送附加数包 数包数窗口中丢失种情况发送端重传数包(第 次进入快速重传时重传数包)确认时获第条新信息果数包丢失重传数包确认确认进入快速重传(没重新排序 情况)前发送数包数包丢失时重传数包确认确认快速重传前发送数包称包部分确认 许建议起[Hoe95]建议快速恢复期间TCP数发送端通推断声明 数包已
    丢失重传数包方式响应部分确认
    说明选择重传(sack)TCP协议处仿真TCP SACK 网络仿真器TCP SACK TCP Reno 适扩展 解决拥塞采基窗口端端算法前两种:Tahoe Reno分通重复应答者收重复应答时律认网络发生拥塞Reno收重复应答时认网络暂时持久拥塞Reno导致窗口中出现数包丢失现象Tahoe 包括慢启动拥塞避免快速重传等阶段着网络技术发展Reno算法基础出现New Reno 算法

    译文2 The Algorithm of Congestion Control
    1.Tahoe TCP
    Modern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput Early TCP implementations followed a gobackn model using cumulative positive acknowledgment and requiring a retransmit timer expiration to resend data lost during transport These TCPs did little to minimize network congestion
    The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations The new algorithms include SlowStart Congestion Avoidance and Fast Retransmit The refinements include a modification to the roundtrip time estimator used to set retransmission timeout values All modifications have been described elsewhere
    The Fast Retransmit algorithm is of special interest in this paper because it is modified subsequent versions of TCP With Fast Retransmit after receiving a small number of duplicate acknowledgments for the same TCP segment (dup ACKs) the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmission timer to expire leading to higher channel utilization and connection throughput
    2.Reno TCP
    The Reno TCP implementation retained the enhancements incorporated into Tahoe but modified the Fast Retransmit operation to include Fast Recovery The new algorithm prevents the communication path (pipe) from going empty after Fast Retransmit thereby avoiding the need to SlowStart to refill it after a single packet loss Fast Recovery operates by assuming each dup ACK received represents a single packet having left the pipe Thus during Fast Recovery the TCP sender is able to make intelligent estimates of the amou
    nt of outstanding data
    In Reno the sender's usable window becomes other gateways that fail to monitor the average queue size) until the number of dup ACKs reaches tcprexmtthresh and thereafter tracks the number of duplicate ACKs Thus during Fast Recovery the sender inflate its window by the number of dup ACKs it has received according to the observation that each dup ACK indicates some packet has been removed from the network and is now cached at the receiver After entering Fast Recovery and retransmitting a single packet the sender effectively waits until half a window of dup ACKs have been received and then sends a new packet for each additional dup ACK that is received
    3.NewReno TCP
    We include NewReno TCP in this paper to show how a simple change to TCP makes it possible to avoid some of the performance problems of Reno TCP without the addition of SACK At the same time we use NewReno TCP to explore the fundamental limitations of TCP performance in the absence of SACK
    The NewReno TCP in this paper includes a small change to the Reno algorithm at the sender that eliminates Reno's wait for a retransmit timer when multiple packets are lost from a window The change concerns the sender's behavior during Fast Recovery when a partial ACK is received that acknowledges some but not all of the packets that were outstanding at the start of that Fast Recovery period In Reno partial ACKs take TCP out of Fast Recovery by deflating the usable window back to the size of the congestion window In NewReno partial ACKs do not take TCP out of Fast Recovery Instead partial ACKs received during Fast Recovery are treated as an indication that the packet immediately following the acknowledged packet in the sequence space has been lost and should be retransmitted Thus when multiple packets are lost from a single window of data NewReno can recover without a retransmission timeout retransmitting one lost packet per roundtrip time until all of the lost packets from that window have been retransmitted NewReno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged
    The implementations of NewReno and SACK TCP in our simulator also use a maxburst parameter In our SACK TCP implementation the maxburst parameter limits to four the number of packets that can be sent in response to a single incoming ACK even if the sender's congestion window would allow more packets to be sent In NewReno the maxburst parameter is set to four packets outs
    ide of Fast Recovery and to two packets during Fast Recovery to more closely reproduce the behavior of Reno TCP during Fast Recovery The maxburst parameter is really only needed for the first window of packets that are sent after leaving Fast Recovery If the sender had been prevented by the receiver's advertised window from sending packets during Fast Recovery then without maxburst it is possible for the sender to send a large burst of packets upon exiting Fast Recovery This applies to Reno and NewReno TCP and to a lesser extent to SACK TCP In Tahoe TCP the SlowStart algorithm prevents bursts after recovering from a packet loss The bursts of packets upon exiting Fast Recovery with NewReno TCP are illustrated in Section 6 in the simulations with three and four packet drops Bursts of packets upon exiting Fast Recovery with Reno TCP are illustrated in
    4.SACK TCP
    The SACK option follows the format in [MMFR96] From [MMFR96] the SACK option field contains a number of SACK blocks where each SACK block reports a noncontiguous set of data that has been received and queued The first block in a SACK option is required to report the data receiver's most recently received segment and the additional SACK blocks repeat the most recently reported SACK blocks [MMFR96] In these simulations each SACK option is assumed to have room for three SACK blocks When the SACK option is used with the Timestamp option specified for TCP Extensions for High Performance then the SACK option has room for only three SACK blocks [MMFR96] If the SACK option were to be used with both the Timestamp option and with TTCP (TCP Extensions for Transactions) the TCP option space would have room for only two SACK blocks
    The 1990 Sack TCP implementation on our previous simulator is from Steven McCanne and Sally Floyd and does not conform to the formats in [MMFR96] The new Sack1implementation contains major contributions from Kevin Fall Jamshid Mahdavi and Matt Mathis
    The congestion control algorithms implemented in our SACK TCP are a conservative extension of Reno's congestion control in that they use the same algorithms for increasing and decreasing the congestion window The SACK TCP implementation in this paper called Sack1in our simulator is also discussed in and make minimal changes to the other congestion control algorithms Adding SACK to TCP does not change the basic underlying congestion control algorithms The SACK TCP implementation preserves the properties of Tahoe and Reno TCP of being robust in
    the presence of outoforder packets and uses retransmit timeouts as the recovery method of last resort The main difference between the SACK TCP implementation and the Reno TCP implementation is in the behavior when multiple packets are dropped from one window of data

    拥塞控制中算法
    1.Tahoe TCP
    TCP Tahoe指1988年加入Van Jacobson提出慢启动拥塞避免快速重传算法43BSD类似TCP实现版正RFC793求Tahoe采递增式肯定重传策略gobackn模型(滑动窗口算法)慢启动阶段拥塞窗口(cwnd)着确认指数方式递增(种ACK触发TRANSMIT机制VJ称ACK clockingselfclocking)直达阀值ssthresh(slow start threshold)TCP进入拥塞避免阶段cwnd隔RTT线性方式递增1单位果连续收3重复确认TCP等重传定时器溢出马重传丢失报文段称快速重传TCP返回慢启动状态早期TCP实现算法基积极响应通重传重发丢失数丢包时TCP减拥塞窗口重传丢失分组然网络拥塞达方面算法性差TCP Tahoe 参考早期实现方法增加算法包括慢启动:窗口指数速度增加拥塞避免:窗口线形速度增加快速重传:丢包状态恢复需等重传定时器超时Tahoe 包括返时间估计量修改参数准确估计非常重设置重传超时定时器基值外Tahoe引入快速重传机制接受者收TCP报文相应答时发送方推断已发生丢包没必等重传定时器超时重传相应包提高信道利率
    2.Reno TCP
    TCP Reno快速重传进入快速恢复(TCP Tahoe采慢启动)VJ出原接收方发送重复确认仅仅意味着报文段丢失意味着()报文段离开网络达接收方缓区(selfclocking)说网络道空出新位置样TCP继续发送新报文段(然cwnd应该减)进入慢启动原dup ACKs达已发送方确认时钟步快速重传快速恢复通常起实现:1 收第3重复确认令
    ssthresh max(FlightSize22*SMSS)2 重传丢失报文段令cwnd ssthresh +33 dupACKcwnd + SMSS时窗口允许话发送报文段4 确认新数ACK达时令cwndssthresh进入拥塞避免状态
    TCP Reno窗口中报文段时丢失情况会出现性问题时引起TCP退出快速恢复确认新数ACK没确认进入快速重传前丢失报文段丢失报文段会TCP断执行快速重传快速恢复cwndssthresh会次减半降低吞吐量 Reno修改Tahoe快速重传快速恢复(指三重复应答判断包丢失时仅窗口值减半)新算法防止通信道快速重传变空避免慢启动单包丢失重填快速重传决定收重复应答数目初始门限值旦达门限值发送方重传数包时拥塞窗口减半Tahoe慢启动Reno发送方额外达应答续包定时发送方窗口变发送窗口拥塞窗口值快速恢复中发送方根收重复应答变动窗口相应重复应答表示包已移出网络现已达接收方进入快速恢复阶段重发数包应额外重复应答传出新包接受新数应答时发送方退出快速恢复阶段设置Ndup0
    Reno理想情况窗口中单包丢失时Reno 发送方返时间中重传包窗口中出现包丢失时出现问题
    3.New Reno TCP
    TCP NewReno修改TCP Reno快速恢复算法处理窗口中报文段时丢失时出现部分确认(partial ACKs快速恢复阶段达确认新数确认进入快速重传前发送部分数)种情况TCP Reno会退出快速恢复状态等重传定时器溢出者dup ACKs达TCP NewReno退出快速恢复状态 (1)重传紧接着partial ACK报文段(2)cwndpartial ACK确认新数cwnd+SMSS(3)第(建议)partial ACK复位重传定时器
    New Reno 做变化包丢弃时掉Reno等重传定时器快速恢复阶段发送端收部分应答表征包包阶段起始时间没成功传送Reno中部分包通减少窗口拥塞窗口TCP退出快速恢复New Reno 中部分应答包已丢失需重传New Reno 恢复需重传超时返时间重传包直数包传完New Reno 保持快速恢复状态直快速恢复阶段初始化未成功传送数全响应
    4.SACK TCP
    前面种算法单包丢弃时效果错果窗口数窗口性较局限性出现基选择应答(sack)算法较解决数包丢失问题种算法基原理样:SACK算法中称作选择域(option)数段:SACK选择域数段ACK中SACK域包含定数量SACK块SACK块记录信宿端接收缓存非连续分组SACK块少应需Reno相似发送端收prexmtthresh重复ACK时重发丢失分组拥塞窗口减半进入快速恢复程期间SACK维护称pipe变量估计出现网络中分组数pipe拥塞窗口时发送端发送新需重发分组变量pipe加发送端接收带SACK选项重复ACK表明新分组已接收端接收pipe变量减Pipe变量时发送发送分组效解偶发送端许发送分组时次发送丢失列表中记录分组果没样分组接收端通报窗口足够发送端发出新数分组
    重传分组身丢弃SACK重传超时探测丢失次重传进入慢启动程确认出现进入快速恢复阶段分组发送端快速恢复中退出TCP SACK TCP Reno区数包丢失情况进行拥塞避免方式
    文档香网(httpswwwxiangdangnet)户传

    《香当网》用户分享的内容,不代表《香当网》观点或立场,请自行判断内容的真实性和可靠性!
    该内容是文档的文本内容,更好的格式请下载文档

    下载文档到电脑,查找使用更方便

    文档的实际排版效果,会与网站的显示效果略有不同!!

    需要 10 香币 [ 分享文档获得香币 ]

    下载文档

    相关文档

    项目开发中的成本控制研究

    项目开发中的成本控制研究  摘要:在我国许多施工企业在成本控制方面存在许多问题,影响了企业的经济效益。从项目开工前的成本预测、施工中的成本控制和竣工时的工程结算三方面,详细阐述了项目开发中的成...

    10年前   
    516    0

    浅谈进度控制和质量控制在工程中的相互作用

    浅谈进度控制和质量控制在工程中的相互作用  摘 要:在工程建设中,加快进度往往要增加投资,采取各种措施使工程建设项目及早竣工,尽快发挥工程建设投资的经济效益;而加快进度,因人、机械超强工作造成...

    12年前   
    569    0

    进度控制和质量控制在施工中的作用与关系

    进度控制和质量控制在施工中的作用与关系摘要:工程建设项目质量、进度和投资是对立和统一的矛盾体。它在工程建设中投资与进度的关系是加快进度往往要增加投资,采取各种赶工措施使工程建设项目及早竣工,尽...

    12年前   
    463    0

    《内部控制审计研究》

    本科生毕业设计(论文)封面( 2017 届)论文(设计)题目 作 者 ...

    2年前   
    805    0

    液压系统中的方向控制阀毕业论文

    液压系统中的方向控制阀毕业论文 摘 要 近几年来,我国经济迅猛,可谓日新月异,新的形势对液压控制阀的工作要求提出了新的要求,在新的形势下,如何改良液压控制阀的工作效率,满足市场需求,已成...

    5年前   
    1372    0

    项目执行中的成本控制

    项目执行中的成本控制  在项目执行过程中,如何有效的控制项目的运行成本,这是大家普遍比较关注的事情,也是考核项目经理和他的团队绩效的重要指标。  一个好的成本控制是从计划开始的,主要需要完成的...

    9年前   
    587    0

    项目管理过程中成本控制的有效途径研究

    项目管理过程中成本控制的有效途径研究在以往的工作中,项目管理者往往只注重现场管理,而忽视工程成本和利润;许多公司也往往是以施工进度等现场管理情况对项目管理者进行考核,而不对成本进行考核。然而,...

    8年前   
    613    0

    住宅小区项目工程监理中的质量控制研究

      住宅小区项目工程监理中的质量控制研究 摘要:随着住房制度的改革和经济适用住房的大规模建设,成片开发的住宅小区越来越多,住宅工程必须实行监理已经列入国家的政策法规中。在住宅小区的工程监理...

    7年前   
    4296    0

    论软件项目管理中质量控制模型的应用研究

    论软件项目管理中质量控制模型的应用研究摘要:从“质量”概念中所涵盖的两大要素(质量的相对性、质量的经济性)出发,系统论述了软件质量管理的重要性。结合软件组织能力进程的成熟度模型(CMM)列举出...

    9年前   
    529    0

    软件项目管理中质量控制的研究与应用

    软件项目管理中质量控制的研究与应用  [摘 要]我国软件业与世界先进国家相比,差距甚远,其主要原因是软件工程化技术没有得到广泛的应用。今天,软件开发不再是软件开发人员的个人行为而是团队行为,对...

    9年前   
    378    0

    电信运营商流量控制解决方案-通信解决方案

    电信运营商流量控制解决方案-通信解决方案  随着网络的发展,大量动态应用流量日益取代HTTP等传统的网络流量而占据流量榜上的前列,而且比例甚至已经达到一半以上。其中最具备代表性的是PTP下载和...

    10年前   
    571    0

    机器人的运动与控制毕业论文

    本科学生毕业论文机器人的运动与控制作  者     院(系)  物理与电气工程学院  专  业  电气工程与自动化   年  级   ...

    4年前   
    633    0

    工程造价控制毕业论文

     毕业论文 题 目: 《浅谈如何进行工程造价的控制》 院 属: 建筑工程学院 专 业: ...

    5年前   
    1167    0

    GPS城市控制网设计毕业论文

    梧州市GPS城市控制网设计 目录 梧州市GPS城市控制网设计目录………….. …………… ………1 中文摘要…………………………………………. ……………….3 英文摘要…………………...

    5年前   
    938    0

    毕业论文 公司成本控制的调研报告

     学生毕业论文 题目:***有限公司成本控制的调研报告   对于一家企业来说,有效地实施成本控制是管理者认为最重要、最头疼的问题之一。企业生产营业每一项都要花钱:采购原材料、生...

    9年前   
    12092    1

    成本控制的方法和手段

    成本控制的方法和手段《成本控制的方法和手段》控制采购成本对一个企业的经营业绩至关重要。采购成本下降不仅体现在企业现金流出的减少,而且直接体现在産品成本的下降、利润的增加,以及企业竞争力的增强。...

    8年前   
    618    0

    工程造价计价模式和造价控制的研究

    本论文首先阐明了定额计价和工程量清单计价模式的基本概念以及计算费用的步骤,比较区分了两者之间的不同点,由此得出工程量清单计价模式在我国推行的必要性。其次,主要剖析了工程量清单计价模式下的造价控制...

    3年前   
    588    0

    GPS控制测量和图根控制测量技术总结

    受**市城市规划勘测设计研究院的委托,**第一测绘院于2003年4月18日至31日,对**市**区南庄镇湖涌测区进行了一级GPS控制测量和图根控制测量。现将有关技术情况总结如下。 1.   ...

    12年前   
    14672    0

    论项目管理中的进度成本和质量控制

    论项目管理中的进度成本和质量控制  [摘要]施工项目的质量、进度、成本是项目管理的主要内容,简要介绍了进度、成本、质量相互之间的对立统一关系,对进度控制、成本控制、质量控制的控制措施进行了详细...

    9年前   
    542    0

    服饰公司成本控制研究

    题 目 服饰公司成本控制研究 目 录摘 要 11绪论 21.1 研究背景和意义 21.1.1 研究背景 21.1.2 研究意义 31.2 国内外研究现状 41.2.1 国外...

    11个月前   
    284    0

    文档贡献者

    文***品

    贡献于2020-08-17

    下载需要 10 香币 [香币充值 ]
    亲,您也可以通过 分享原创文档 来获得香币奖励!
    下载文档

    该用户的其他文档