الدرس · طبقة النقل · IT1340

مقدمة الفصل

ماذا ستتعلم في هذا الفصل

Understand principles behind transport layer services: multiplexing, demultiplexing; reliable data transfer; flow control; congestion control.
Learn about Internet transport layer protocols: UDP (connectionless transport), TCP (connection-oriented reliable transport), TCP congestion control.

أقسام الفصل

1Transport services and protocolsخدمات النقل وبروتوكولاته
2Multiplexing and demultiplexingتعدد الإرسال وفكّه
3UDP: User Datagram Protocolبروتوكول UDP
4Principles of reliable data transfer: rdt1.0 to rdt2.2مبادئ النقل الموثوق: من rdt1.0 إلى rdt2.2
5rdt3.0 and its performancerdt3.0 وأداؤه
6Pipelined protocols: Go-Back-N and Selective Repeatالبروتوكولات الأنبوبية: GBN وSelective Repeat
7TCP overview, segment structure, sequence numbersنظرة على TCP ومقطعه وأرقام التسلسل
8TCP reliable data transferالنقل الموثوق في TCP
9TCP flow controlالتحكم في التدفق في TCP
10TCP connection managementإدارة اتصال TCP
11Principles of congestion controlمبادئ التحكم في الازدحام
12TCP congestion controlالتحكم في ازدحام TCP

تلميح: استخدم أسهم لوحة المفاتيح للتنقل بين الشرائح.

Transport services and protocolsخدمات النقل

Transport layer

Provides logical communication between app processes running on different hosts.

Transport protocols run in end systems.
Send side: breaks app messages into segments, passes to network layer.
Rcv side: reassembles segments into messages, passes to app layer.
More than one transport protocol available to apps — Internet: TCP and UDP.

Network layer

Logical communication between hosts
Analogy: postal service

Transport layer

Logical communication between processes
Relies on, enhances, network layer services
Analogy: Ann and Bill, who demux letters to in-house siblings

من الشرائح

Household analogy: hosts = houses; processes = kids; app messages = letters in envelopes.

Internet transport-layer protocolsTCP وUDP باختصار

Transport services and protocols

TCP

Reliable, in-order delivery
Congestion control
Flow control
Connection setup

UDP

Unreliable, unordered delivery
No-frills extension of "best-effort" IP

Services not available

Delay guarantees
Bandwidth guarantees

Multiplexing and demultiplexingتعدد الإرسال وفكّه

Multiplexing at senderتعدد الإرسال

Handle data from multiple sockets, add transport header (later used for demultiplexing).

Demultiplexing at receiverفكّ التعدد

Use header info to deliver received segments to correct socket.

How demultiplexing works

Host receives IP datagrams: each has source IP address and destination IP address.
Each datagram carries one transport-layer segment; each segment has source and destination port number.
Host uses IP addresses & port numbers to direct segment to appropriate socket.

Connectionless vs connection-oriented demuxفكّ التعدد في UDP وTCP

Multiplexing and demultiplexing

Connectionless demux (UDP)

Receiver checks destination port # in segment and directs it to the socket with that port #
IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers, go to the same socket at dest

Connection-oriented demux (TCP)

TCP socket identified by 4-tuple: source IP, source port, dest IP, dest port
Receiver uses all four values to direct segment to appropriate socket
Web servers have different sockets for each connecting client; non-persistent HTTP will have a different socket for each request

من الشرائح

Slide 13: three segments, all destined to IP address B, dest port 80 — from (A, 9157), (C, 5775) and (C, 9157) — are demultiplexed to different sockets.

Two different clients send segments to port 5000 on server S. Under which protocol are both segments necessarily delivered to the same socket on S?

aUDP, because UDP demultiplexes by destination port # onlybTCP, because the destination port is the samecBoth TCP and UDPdNeither

UDP: User Datagram Protocolبروتوكول UDP

UDP [RFC 768]

"No frills," "bare bones" Internet transport protocol; "best effort" service: UDP segments may be lost or delivered out-of-order to app. Connectionless: no handshaking between UDP sender, receiver; each UDP segment handled independently of others.

UDP use

Streaming multimedia apps (loss tolerant, rate sensitive)
DNS
SNMP
Reliable transfer over UDP: add reliability at application layer — application-specific error recovery!

UDP segment header

Source port #, dest port #
Length, in bytes of UDP segment, including header
Checksum
Application data (payload)

Why is there a UDP?

No connection establishment (which can add delay)
Simple: no connection state at sender, receiver
Small header size
No congestion control: UDP can blast away as fast as desired

UDP checksumالمجموع الاختباري

UDP: User Datagram Protocol

Goal

Detect "errors" (e.g., flipped bits) in transmitted segment.

Sender

Treat segment contents, including header fields, as sequence of 16-bit integers
Checksum: addition (one's complement sum) of segment contents
Put checksum value into UDP checksum field

Receiver

Compute checksum of received segment
Check if computed checksum equals checksum field value
NO — error detected
YES — no error detected. But maybe errors nonetheless?

Reliable data transfer: getting startedبداية النقل الموثوق

Principles of reliable data transfer: rdt1.0 to rdt2.2

Principles of reliable data transfer (slides 22–23)

Important in application, transport and link layers — on the "top-10 list of important networking topics"!
(a) Provided service: the sending process passes data down a reliable channel to the receiver process.
(b) Service implementation: rdt_send() → reliable data transfer protocol (sending side) → udt_send() → unreliable channel → rdt_rcv() → reliable data transfer protocol (receiving side) → deliver_data().
Characteristics of the unreliable channel will determine the complexity of the reliable data transfer protocol (rdt).

Reliable data transfer is important in application, transport and link layers. Characteristics of the unreliable channel will determine the complexity of the reliable data transfer protocol (rdt).

rdt_send()

Called from above (e.g., by app). Passed data to deliver to receiver upper layer.

udt_send()

Called by rdt, to transfer packet over unreliable channel to receiver.

rdt_rcv()

Called when packet arrives on rcv-side of channel.

deliver_data()

Called by rdt to deliver data to upper layer.

Incrementally develop sender, receiver sides of rdt.
Consider only unidirectional data transfer — but control info will flow on both directions!
Use finite state machines (FSM) to specify sender, receiver.
rdt1.0: underlying channel perfectly reliable (no bit errors, no loss of packets); separate FSMs for sender and receiver.

rdt2.0: channel with bit errorsrdt2.0

Principles of reliable data transfer: rdt1.0 to rdt2.2

Underlying channel may flip bits in packet; checksum to detect bit errors.

ACKs

Receiver explicitly tells sender that pkt received OK.

NAKs

Receiver explicitly tells sender that pkt had errors. Sender retransmits pkt on receipt of NAK.

rdt2.0 has a fatal flaw!

What happens if ACK/NAK corrupted? Sender doesn't know what happened at receiver; can't just retransmit: possible duplicate.
Handling duplicates: sender retransmits current pkt if ACK/NAK corrupted; sender adds sequence number to each pkt; receiver discards (doesn't deliver up) duplicate pkt.
Stop and wait: sender sends one packet, then waits for receiver response.

rdt2.0 and rdt2.2: the state machinesآلات الحالة rdt2.0 وrdt2.2

Principles of reliable data transfer: rdt1.0 to rdt2.2

rdt2.0: FSM specification — sender (slide 29); Λ = no action

From state	Event (above the line)	Actions (below the line)	To state
Wait for call from above	rdt_send(data)	sndpkt = make_pkt(data, checksum) udt_send(sndpkt)	Wait for ACK or NAK
Wait for ACK or NAK	rdt_rcv(rcvpkt) && isNAK(rcvpkt)	udt_send(sndpkt)	Wait for ACK or NAK
Wait for ACK or NAK	rdt_rcv(rcvpkt) && isACK(rcvpkt)	Λ	Wait for call from above

rdt2.0 — receiver (slide 29)

From state	Event (above the line)	Actions (below the line)	To state
Wait for call from below	rdt_rcv(rcvpkt) && corrupt(rcvpkt)	udt_send(NAK)	Wait for call from below
Wait for call from below	rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)	extract(rcvpkt, data) deliver_data(data) udt_send(ACK)	Wait for call from below

Operation with no errors (slide 30): rdt_send → packet sent → receiver finds it not corrupt, delivers and sends ACK → sender gets the ACK and waits for the next call from above.
Error scenario (slide 31): the receiver finds the packet corrupt and sends NAK → the sender retransmits (udt_send(sndpkt)) → the retransmission arrives uncorrupted, is delivered and ACKed.

rdt2.2: sender FSM fragment (slide 37) — no NAK; the ACK carries a sequence number

From state	Event (above the line)	Actions (below the line)	To state
Wait for call 0 from above	rdt_send(data)	sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt)	Wait for ACK 0
Wait for ACK 0	rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) \|\| isACK(rcvpkt,1) )	udt_send(sndpkt)	Wait for ACK 0
Wait for ACK 0	rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)	Λ	(next state not drawn in the fragment)

rdt2.2: receiver FSM fragment (slide 37)

From state	Event (above the line)	Actions (below the line)	To state
Wait for 0 from below	rdt_rcv(rcvpkt) && (corrupt(rcvpkt) \|\| has_seq1(rcvpkt))	udt_send(sndpkt)	Wait for 0 from below
(previous state; not drawn in the fragment)	rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)	extract(rcvpkt, data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)	Wait for 0 from below

rdt2.1 and rdt2.2rdt2.1 وrdt2.2

Principles of reliable data transfer: rdt1.0 to rdt2.2

rdt2.1: discussion (slide 35)

Sender

Seq # added to pkt
Two seq. #'s (0,1) will suffice
Must check if received ACK/NAK corrupted
Twice as many states: must "remember" whether "expected" pkt should have seq # of 0 or 1

Receiver

Must check if received packet is duplicate (state indicates whether 0 or 1 is expected pkt seq #)
Note: receiver can not know if its last ACK/NAK received OK at sender

rdt2.2: a NAK-free protocol

Same functionality as rdt2.1, using ACKs only: instead of NAK, receiver sends ACK for last pkt received OK, explicitly including the seq # of the pkt being ACKed. Duplicate ACK at sender results in same action as NAK: retransmit current pkt.

rdt3.0: channels with errors and lossrdt3.0

rdt3.0 and its performance

New assumption: the underlying channel can also lose packets (data, ACKs). Checksum, seq. #, ACKs and retransmissions will be of help… but not enough.

Approach

1
Sender waits a "reasonable" amount of time for ACK.
2
Retransmits if no ACK received in this time.
3
If pkt (or ACK) was just delayed (not lost): retransmission will be duplicate, but seq. #'s already handles this; receiver must specify seq # of pkt being ACKed.
4
Requires countdown timer.

rdt3.0 in action (slides 40–41)

(a) no loss
(b) packet loss
(c) ACK loss
(d) premature timeout / delayed ACK

rdt3.0 sender (slide 39); Λ = no action

From state	Event (above the line)	Actions (below the line)	To state
Wait for call 0 from above	rdt_send(data)	sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer	Wait for ACK0
Wait for call 0 from above	rdt_rcv(rcvpkt)	Λ	Wait for call 0 from above
Wait for ACK0	rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) \|\| isACK(rcvpkt,1) )	Λ	Wait for ACK0
Wait for ACK0	timeout	udt_send(sndpkt) start_timer	Wait for ACK0
Wait for ACK0	rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)	stop_timer	Wait for call 1 from above
Wait for call 1 from above	rdt_rcv(rcvpkt)	Λ	Wait for call 1 from above
Wait for call 1 from above	rdt_send(data)	sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer	Wait for ACK1
Wait for ACK1	rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) \|\| isACK(rcvpkt,0) )	Λ	Wait for ACK1
Wait for ACK1	timeout	udt_send(sndpkt) start_timer	Wait for ACK1
Wait for ACK1	rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)	stop_timer	Wait for call 0 from above

Performance of rdt3.0 (stop-and-wait)أداء أرسل وانتظر

rdt3.0 and its performance

U_sender

Utilization — fraction of time sender busy sending.

المسألة

1 Gbps link, 15 ms prop. delay (RTT = 30 msec), 8000 bit packet

المعطيات

L: 8000 bits
R: 10⁹ bits/sec
RTT: 30 msec

الصيغة

U_sender = (L/R) / (RTT + L/R)

Pipelined protocolsالإرسال الأنبوبي

Pipelining

Sender allows multiple, "in-flight", yet-to-be-acknowledged pkts. Range of sequence numbers must be increased; buffering at sender and/or receiver.

المسألة

3-packet pipelining (slide 45)

الصيغة

U_sender = (3L/R) / (RTT + L/R)

خطوات الحل

= .0024 / 30.008

النتيجة

= 0.00081 — 3-packet pipelining increases utilization by a factor of 3!

Two generic forms of pipelined protocols (slide 46)

	Go-Back-N	Selective Repeat
Unacked packets in pipeline	Up to N	Up to N
ACKs	Receiver only sends cumulative ack doesn't ack packet if there's a gap	Rcvr sends individual ack for each packet
Timers	Sender has timer for oldest unacked packet	Sender maintains timer for each unacked packet
On timeout	Retransmit all unacked packets	Retransmit only that unacked packet
Out-of-order packets at receiver	Discarded (no receiver buffering)	Buffered for eventual in-order delivery

Go-Back-NGo-Back-N

GBN sender

k-bit seq # in pkt header; "window" of up to N consecutive unack'ed pkts allowed
ACK(n): ACKs all pkts up to, including seq # n — "cumulative ACK"; may receive duplicate ACKs
Timer for oldest in-flight pkt
timeout(n): retransmit packet n and all higher seq # pkts in window

GBN receiver

ACK-only: always send ACK for correctly-received pkt with highest in-order seq # (may generate duplicate ACKs; need only remember expectedseqnum)
Out-of-order pkt: discard (don't buffer): no receiver buffering! Re-ACK pkt with highest in-order seq #

GBN in action (N = 4; pkt2 lost)

1
Sender sends pkt0–pkt3; receiver gets pkt0, pkt1 and sends ack0, ack1. pkt2 is lost.
2
Receiver gets pkt3: discards it, (re)sends ack1.
3
Sender (on ack0, ack1) sends pkt4, pkt5; receiver discards each and (re)sends ack1; sender ignores duplicate ACKs.
4
pkt 2 timeout: sender sends pkt2, pkt3, pkt4, pkt5 again.
5
Receiver delivers pkt2, pkt3, pkt4, pkt5 and sends ack2–ack5.

Selective RepeatSelective Repeat

Receiver individually acknowledges all correctly received pkts; buffers pkts, as needed, for eventual in-order delivery to upper layer.
Sender only resends pkts for which ACK not received; sender timer for each unACKed pkt.
Sender window: N consecutive seq #'s; limits seq #s of sent, unACKed pkts.

Selective repeat: sender, receiver windows (slide 52) — window size N

View	Pointer	Sequence-number states
(a) Sender	send_base (start of window), nextseqnum	already ack'ed sent, not yet ack'ed usable, not yet sent not usable
(b) Receiver	rcv_base (start of window)	out of order (buffered) but already ack'ed expected, not yet received acceptable (within window) not usable

Selective Repeat sender

Data from above: if next available seq # in window, send pkt
timeout(n): resend pkt n, restart timer
ACK(n) in [sendbase, sendbase+N]: mark pkt n as received; if n smallest unACKed pkt, advance window base to next unACKed seq #

Selective Repeat receiver

pkt n in [rcvbase, rcvbase+N−1]: send ACK(n); out-of-order: buffer; in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase−N, rcvbase−1]: ACK(n)
Otherwise: ignore

من الشرائح

Selective Repeat in action (N = 4, pkt2 lost): receiver buffers pkt3, pkt4, pkt5 and sends ack3, ack4, ack5; at pkt 2 timeout only pkt2 is resent; then pkt2–pkt5 are delivered and ack2 is sent.

With window N = 4, packets 0–5 are sent and packet 3 is lost; everything else arrives. When packet 3's timer expires, which packets are retransmitted under Go-Back-N and under Selective Repeat?

aGBN: 3 only; Selective Repeat: 3, 4, 5bGBN: 3, 4, 5; Selective Repeat: 3 onlycBoth: 3 onlydBoth: 3, 4, 5

TCP overview and segment structureنظرة على TCP

TCP overview, segment structure, sequence numbers

Point-to-point
Reliable, in-order byte stream
Pipelined
Full duplex data
Connection-oriented
Flow controlled

Field	Meaning on slide 57
Source port #, dest port #	Ports, as in every segment
Sequence number, acknowledgement number	Counting by bytes of data (not segments!)
ACK flag	ACK # valid
RST, SYN, FIN flags	Connection estab (setup, teardown commands)
URG, PSH flags	Urgent data / push data now (generally not used)
Receive window	# bytes rcvr willing to accept
Checksum	Internet checksum (as in UDP)

TCP sequence numbers and ACKsأرقام التسلسل والإقرار

TCP overview, segment structure, sequence numbers

Sequence numberرقم التسلسل

Byte stream "number" of first byte in segment's data.

Acknowledgementرقم الإقرار

Seq # of next byte expected from other side; cumulative ACK.

المسألة

Simple telnet scenario (slide 59): the user types 'C'

خطوات الحل

Host A → B: Seq=42, ACK=79, data = 'C'
Host B → A (ACKs receipt of 'C', echoes back 'C'): Seq=79, ACK=43, data = 'C'
Host A → B (ACKs receipt of echoed 'C'): Seq=43, ACK=80

النتيجة

Each ACK number is the next byte expected: 42 + 1 = 43 and 79 + 1 = 80.

Setting the timeout (slide 60)

Longer than RTT — but RTT varies.
Too short: premature timeout, unnecessary retransmissions. Too long: slow reaction to segment loss.
SampleRTT: measured time from segment transmission until ACK receipt; ignore retransmissions. Want estimated RTT "smoother": average several recent measurements, not just current SampleRTT.

TCP reliable data transfer: sender eventsأحداث مرسل TCP

TCP creates rdt service on top of IP's unreliable service: pipelined segments, cumulative acks, single retransmission timer. Retransmissions are triggered by timeout events and duplicate acks.

Data rcvd from app

Create segment with seq # (byte-stream number of first data byte in segment); start timer if not already running (timer for oldest unacked segment; expiration interval: TimeOutInterval).

Timeout

Retransmit segment that caused timeout; restart timer.

Ack rcvd

If ack acknowledges previously unacked segments: update what is known to be ACKed; start timer if there are still unacked segments.

Retransmission scenarios (slides 64–65)

lost ACK scenario
premature timeout
cumulative ACK

TCP ACK generationتوليد الإقرار في TCP

TCP reliable data transfer

TCP ACK generation [RFC 1122, RFC 2581] (slide 66)

Event at receiver	TCP receiver action
Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed	Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK
Arrival of in-order segment with expected seq #. One other segment has ACK pending	Immediately send single cumulative ACK, ACKing both in-order segments
Arrival of out-of-order segment higher-than-expect seq. #. Gap detected	Immediately send duplicate ACK, indicating seq. # of next expected byte
Arrival of segment that partially or completely fills gap	Immediate send ACK, provided that segment starts at lower end of gap

TCP fast retransmitإعادة الإرسال السريع

TCP reliable data transfer

Time-out period often relatively long: long delay before resending lost packet.
Detect lost segments via duplicate ACKs: sender often sends many segments back-to-back; if a segment is lost, there will likely be many duplicate ACKs.

TCP fast retransmit

If sender receives 3 ACKs for same data ("triple duplicate ACKs"), resend unacked segment with smallest seq # — likely that unacked segment lost, so don't wait for timeout.

من الشرائح

Slide 68: Seq=92 (8 bytes) and Seq=100 (20 bytes) are sent; Seq=100 is lost; Host B keeps answering ACK=100; on receipt of the triple duplicate ACK, Host A resends Seq=100, 20 bytes of data — before the timeout.

TCP flow controlالتحكم في التدفق

Flow control

Receiver controls sender, so sender won't overflow receiver's buffer by transmitting too much, too fast.

1
Application may remove data from TCP socket buffers slower than the TCP receiver is delivering.
2
Receiver "advertises" free buffer space by including the rwnd value in the TCP header of receiver-to-sender segments.
3
Sender limits amount of unacked ("in-flight") data to receiver's rwnd value.
4
Guarantees receive buffer will not overflow.

RcvBuffer size set via socket options (typical default is 4096 bytes); many operating systems autoadjust RcvBuffer.

Connection management: the 3-way handshakeالمصافحة الثلاثية

TCP connection management

Before exchanging data, sender/receiver "handshake"

Agree to establish connection (each knowing the other willing to establish connection).
Agree on connection parameters (seq # client-to-server and server-to-client; rcvBuffer size at server, client).

Will a 2-way handshake always work?

Variable delays; retransmitted messages (e.g., req_conn(x)) due to message loss; message reordering; can't "see" other side.
Failure scenarios: half open connection! (no client!); duplicate data accepted.

TCP 3-way handshake (slide 76)

Client
Choose init seq num x; send TCP SYN msg: SYNbit=1, Seq=x → SYNSENT.
Server
Choose init seq num y; send TCP SYNACK msg, acking SYN: SYNbit=1, Seq=y; ACKbit=1; ACKnum=x+1 → SYN RCVD.
Client
Received SYNACK(x) indicates server is live; send ACK for SYNACK: ACKbit=1, ACKnum=y+1 — this segment may contain client-to-server data → ESTAB.
Server
Received ACK(y) indicates client is live → ESTAB.

Principles of congestion controlمبادئ الازدحام

Congestion

Informally: "too many sources sending too much data too fast for network to handle" — different from flow control!

Manifestations

Lost packets (buffer overflow at routers)
Long delays (queueing in router buffers)

End-end congestion control

No explicit feedback from network
Congestion inferred from end-system observed loss, delay
Approach taken by TCP

Network-assisted congestion control

Routers provide feedback to end systems
Single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
Explicit rate for sender to send at

TCP congestion control: AIMD and slow startAIMD والبداية البطيئة

cwnd

TCP sender congestion window size. Sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs.

Additive increase

Increase cwnd by 1 MSS every RTT until loss detected.

Multiplicative decrease

Cut cwnd in half after loss.

AIMD saw tooth behavior: probing for bandwidth.

TCP Slow Start

When connection begins, increase rate exponentially until first loss event: initially cwnd = 1 MSS; double cwnd every RTT (done by incrementing cwnd for every ACK received). Initial rate is slow but ramps up exponentially fast.

Reacting to loss; fairnessالاستجابة للفقد والعدالة

TCP congestion control

TCP: detecting, reacting to loss (slide 83)

Loss signal	TCP Reno	TCP Tahoe
Timeout	cwnd set to 1 MSS grows exponentially to threshold, then linearly	cwnd set to 1
3 duplicate ACKs	cwnd cut in half then grows linearly	cwnd set to 1

3 dup ACKs indicate network capable of delivering some segments — so Reno only halves cwnd.

TCP fairness

Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K.

الخلاصة

أنهيت الدرس

الخطوة التالية: ثبّت المعلومات بالبطاقات، ثم اختبر نفسك بالأسئلة.

البطاقات التدريب

ما راجعته في هذا الدرس

Transport services and protocolsخدمات النقل وبروتوكولاته
Multiplexing and demultiplexingتعدد الإرسال وفكّه
UDP: User Datagram Protocolبروتوكول UDP
Principles of reliable data transfer: rdt1.0 to rdt2.2مبادئ النقل الموثوق: من rdt1.0 إلى rdt2.2
rdt3.0 and its performancerdt3.0 وأداؤه
Pipelined protocols: Go-Back-N and Selective Repeatالبروتوكولات الأنبوبية: GBN وSelective Repeat
TCP overview, segment structure, sequence numbersنظرة على TCP ومقطعه وأرقام التسلسل
TCP reliable data transferالنقل الموثوق في TCP
TCP flow controlالتحكم في التدفق في TCP
TCP connection managementإدارة اتصال TCP
Principles of congestion controlمبادئ التحكم في الازدحام
TCP congestion controlالتحكم في ازدحام TCP

Transport Layerطبقة النقل

مقدمة الفصل

ماذا ستتعلم في هذا الفصل

أقسام الفصل

Transport services and protocolsخدمات النقل

Internet transport-layer protocolsTCP وUDP باختصار

Multiplexing and demultiplexingتعدد الإرسال وفكّه

Connectionless vs connection-oriented demuxفكّ التعدد في UDP وTCP

UDP: User Datagram Protocolبروتوكول UDP

UDP checksumالمجموع الاختباري

Reliable data transfer: getting startedبداية النقل الموثوق

rdt2.0: channel with bit errorsrdt2.0

rdt2.0 and rdt2.2: the state machinesآلات الحالة rdt2.0 وrdt2.2

rdt2.1 and rdt2.2rdt2.1 وrdt2.2

rdt3.0: channels with errors and lossrdt3.0

Performance of rdt3.0 (stop-and-wait)أداء أرسل وانتظر

Pipelined protocolsالإرسال الأنبوبي

Go-Back-NGo-Back-N

Selective RepeatSelective Repeat

TCP overview and segment structureنظرة على TCP

TCP sequence numbers and ACKsأرقام التسلسل والإقرار

TCP reliable data transfer: sender eventsأحداث مرسل TCP

TCP ACK generationتوليد الإقرار في TCP

TCP fast retransmitإعادة الإرسال السريع

TCP flow controlالتحكم في التدفق

Connection management: the 3-way handshakeالمصافحة الثلاثية

Principles of congestion controlمبادئ الازدحام

TCP congestion control: AIMD and slow startAIMD والبداية البطيئة

Reacting to loss; fairnessالاستجابة للفقد والعدالة

الخلاصة

أنهيت الدرس

ما راجعته في هذا الدرس

خريطة الفصل