COMP3310代写、代写Java/Python程序

日期：2023-04-01 07:55

COMP3310/6331

Transport Layer: TCP/UDP intro

LAN links

Applications don’t know nor care. Unless there is a performance question.

Getting into the transport layer

Leave all the packet to-and-fro to the network layer

Everything here is a payload for IP packets

– A Segment or Datagram

Offers rich functionality (or not) to Applications

– Reliability, performance, security, and other quality measures – on unreliable IP

Routers and other network devices do not get in the way

– They (should) only look at ‘the envelope’ of a message, not the messages

– This is pure host-to-host.

4

Link

e.g. 802.3 IP

Transport T’port Payload

Simple client/server model

Servers offer something,

Clients connect

– Send a request

– Server replies

Servers can handle multiple clients

There are other models!

5

Transport Services

What common application needs are there?

Two options for reliability:

– Reliable - everything has to arrive bit-perfect.

Transport layer repairs packet loss, mis-ordering (and other damage)

I can wait!

– Unreliable

Don’t care about immediate perfection, … Do care about performance, simplicity, …

(and) Two types of communication

– Messages: self-contained command and response (post office)

– Byte-stream: generic flow of bytes, chunked into segments (conversation)

6

Which does what?

Unreliable Reliable

Messages UDP (“Datagrams”)

Byte-stream TCP (“Streams”)

7

Could have reliable messages - but can build that on top of TCP

Could have unreliable byte-streams - but that looks like UDP

Transmission Control Protocol: TCP = IP Protocol 6

User Datagram Protocol: UDP = IP Protocol 17

ICMP = 1, IGMP = 2, IPv6 encapsulation = 41, 130+ more

Compare them

UDP TCP

Connectionless

(minimal state in transport layer)

Connection-oriented

(significant state in transport layer @host)

Delivers MESSAGES:

0-n times, any order

Delivers BYTES: once, reliably, in order

(to your application)

Fixed message size Any number of bytes (in a stream)

Don’t care about flow control Flow control

(sender/receiver negotiate)

Don’t care about congestion Congestion control

(sender/network negotiate)

8

UDP is an enhanced IP packet

TCP is a lifestyle choice – many features

IP Multicast: UDP

Connectionless, maybe time-sensitive

Replica packets are fine!

A

A

A A

Ports

10

Operating System

Net. Interface

Process #1

Process #2

Process #5

Process #3

Process #4

IP is (in theory, not practice) “host-to-host”

Applications are process-to-process

Port: 16bit identifier(s) for a process,

on a host, on an interface,

at each end

Well-known (and other) listening ports

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Opening ports below 1024 requires extra privileges

11

20,21 ftp File transfer

22 ssh Secure shell

25 smtp Email – outbound

80 http Web

110 pop3 Email – inbound

143 imap Email – inbound

443 https Secure-Web

Usually write an application address as IP:port e.g. 150.203.56.90:80

A Port is just a start

Inetd/xinetd

– Don’t continually run every server-service somebody may eventually talk to

– Single service, launch appropriate service on demand

– Listens to all (registered) ports and protocols (tcp, udp)

– Spawns the service to have the conversation

Port mapping

– (e.g. remote procedure calls, bittorrent, …)

– Listen on a well-known port

– Accept connections

– Redirect them to a spawned service on another port

Services can register with the portmapper

12

NAT is actually NA(and Port)T

NAT has everyone ‘hiding’ behind a single public IP address

But everyone wants access to/from the Internet at the same time

So translate addresses and ports

Router maintains a table

– Dynamically for outbound. Can be static for inbound.

13

Internet

150.203.56.99

10.0.0.2 10.0.0.3

10.0.0.4 10.0.0.5

“150.203.56.99:7882 = 10.0.0.2:80”

“150.203.56.99:7884 = 10.0.0.4:80”

10.0.0.1

UDP

UDP adds to IP: Ports, payload length and a Checksum

And nothing else…

14

Ethernet

802.3 IP

UDP UDP Payload

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Source Port Destination Port

Length Checksum

Payload (…)

Byte-streams

TCP segments carry chunks of a byte-stream

– “Message” boundaries are not preserved

Sender OS/driver packetises (eventually) on write()

– Multiple writes can be one packet and vice-versa – buffer dependent

Receiver unpacks

– Applications read() a stream of bytes – in order, without loss

15

DEF BC A …FEDCBA…

…FEDCBA…

TCP segment format

16

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Source port Destination Port

Sequence Number

Acknowledgement Number

N

Window Size

Checksum Urgent Pointer

Options (0 or more)

Payload (optional…)

Ports

Reliability

Performance Acknowledgement Start&Stop

Programming connections

“Socket” programming – an address, a port, and a need to communicate

Connections are uniquely identified in the Operating System by a ‘5-tuple’

– source/destination ip, source/destination port, protocol

17

Host 1 Host 2

connect

request

reply

disconnect

Standard conversation

time

Socket API

18

Primitive (function) What it does

SOCKET Create an object/descriptor

BIND Attach a local address and port (server)

LISTEN (tcp) Tell network layer to get ready (server)

ACCEPT (tcp) Open the door! (server)

CONNECT (tcp) … Connect … (client)

SEND(tcp) or SENDTO(udp) … Send …

RECEIVE(tcp) or RECEIVEFROM(udp) … Receive …

CLOSE Release the connection/socket

So…

Server needs to be prepared for connections

Client initiates the connection

19

connect

request

reply

disconnect

Host 1

Client

Host 2

Server

1. socket()

2. bind()

3. listen()

4. accept() *

1. socket()

5. connect() *

6. recv() *

7. send()

8. recv() * 9. send()

10. close()10. close()

* = call blocks

TCP and reliability

TCP is a reliable, bidirectional byte-stream

– Uses Sequence Numbers and Acknowledgements to provide reliability

Sequence numbers: N-bit counter that wraps (e.g. …,253, 254, 255, 0, 1, 2…)

– Byte count (pointer) in a stream – where sender is up to

Can wrap quickly on high-speed links (232 = 4GB) – can use timestamps too

Does not start from zero (for security)

Acknowledgements: Which byte is expected (which have been received)

– cumulative ACK

20

TCP and reliability

Calculate payload length from increase in Seq #

Losses are obvious

Bidirectional:

– Piggybacks control information on data segments in reverse direction

– If there’s no data, just sends feedback 21

01000 bytes 200400600700

Seq 200Seq 400Seq 600Seq 700Seq 1000

Receiver

Ack 201Ack 401Ack 601Ack 701Ack 1001

Sender

TCP is full-duplex = two simplex paths

– Both need to start together(*)

SYNchronise Sequence numbers in both directions

Connecting

– Receiving transport layer decides:

anybody listen()ing on that port?

– If not, ReSeT

– If yes, passed to receiving process listen()ing,

– Transport layer ACKnowledges, and SYNs own #

– Originator ACKs that SYN/ACK

and off they go

Getting connected – 3 way handshake

22

Both need to end together

– Ideally…

– Time to flush buffers

Disconnecting

– One side initiates close()

– Triggers a FIN(alise)

– Other side ACKs and FINs too

And if FIN is lost? Resend…

Hanging up

23

Socket states:

State Description

LISTEN Accepting connections

ESTABLISHED Connection up and passing data

SYN_SENT Waiting for reply from remote endpoint

SYN_RECV Session requested by remote, for a listen()ing socket

LAST_ACK Closed; remote shut down; waiting for a final ACK

CLOSE_WAIT Remote shut down; kernel waiting for application to close() socket

TIME_WAIT Socket is waiting after close() for any packets left on the network

CLOSED Socket is being cleared

CLOSING Our socket shut; remote shut; not all data has been ACK’ed

FIN_WAIT1 We sent FIN, waiting on ACK

FIN_WAIT2 We sent FIN, got ACK, waiting on their FIN

24

% netstat -n

25

What’s happening on my machine?

TCP Sliding Windows

Want reliability and throughput (of course!)

Start with ARQ – stop-and-wait

– Single segment outstanding = problem on high bandwidth*delay networks

Say one-way-delay=50ms so round-trip-time (RTT)=2d=100ms

Single segment per RTT = 10 segments/s

Typical packet ? Say 1000 bytes = ~10,000 bits -> 100kb/s

Even if bandwidth goes up, throughput doesn’t!

26

TCP Sliding Windows

Allow W bytes to be ‘outstanding’ (unACKed) per RTT

– Fill a pipeline/conveyor-belt with segments

Set up a ‘window’ of W bytes

W=2*Bandwidth*delay (roughly)

At 100Mb/s, one-way-delay=50ms means W=10Mb (~1MB)

– Assuming 10kb segments => W=1000 segments

– They are out there somewhere!

27

N 2

1

1

Sliding Window approach

Sender buffers up W segments until they are ACKed

28

Acked Un-Acked Waiting

Seq#

W=5

Available

Acked Un-Acked Waiting

Acked Un-Acked Waiting

Available

Window not full, so send a packet

Packet ACKed, so Window not full

Receiver Sender

If(lost) then: ARQ – “Go Back N”

Receiver buffers just a single segment

If it’s the next one in sequence, ACK it, everyone happy

If it’s not, drop it,

Let sender retransmit what I’m actually waiting for

Sender has a single timer. After timeout, resend (all) from (first) ACK-less.

Really simple, but somewhat inefficient

29

1 2 3 4 5

Everybody runs the same TCP…?

No. There is no single TCP implementation

Doesn’t impact the network, only hosts, so you can do what you want…

Many years of various optimisations, experiments, algorithms, …

– Suited to various circumstances

– And as vulnerabilities have been found and mitigated (and found and …)