Computer Networking : Principles, Protocols and Practice, 6th lesson : Internet applications and transport layer

1. Week 6
Internet applications
UDP and TCP

2. Agenda
• Internet applications
• DNS
• Email
• Web
• UDP
• TCP

3. DNS messages
Each DNS request contains a number that will be returned in the
response by the server to allow the client to match the request.
32 bits
Identification Flags
12 bytes Number of questions
Number of answers
Number of authority Number of additional
Questions
(variable number of resource records)
Answers
(variable number of resource records)
Authority
(variable number of resource records)
Additional information
(variable number of resource records)
lQuestion/Response
lRecursive question or not
lAuthoritative answer or not
lPossible error

4. Examples
• Wireshark packet traces
• openDNS resovers
• 8.8.8.8
• 2001:4860:4860::8888

5. dig
dig www.ietf.org @2001:4860:4860::8888
; <<>> DiG 9.8.3-P1 <<>> www.ietf.org @2001:4860:4860::8888
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36945
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.ietf.org. IN A
;; ANSWER SECTION:
www.ietf.org. 1441 IN CNAME www.ietf.org.cdn.cloudflare.net.
www.ietf.org.cdn.cloudflare.net. 43 IN A 104.20.1.85
www.ietf.org.cdn.cloudflare.net. 43 IN A 104.20.0.85
;; Query time: 39 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Tue Oct 21 09:16:50 2014

6. dig
• Packets exchanged
sudo tcpdump -n -i en4 -vv udp port 53
tcpdump: listening on en4, link-type EN10MB (Ethernet), capture size 262144 bytes
09:16:50.749400 IP6 (flowlabel 0x8ea5d, hlim 64, next-header UDP (17) payload length: 38)
2001:6a8:3080:2:2908:3cb4:bbb4:ae0e.56551 > 2001:4860:4860::8888.53: [bad udp cksum 0x602c
-> 0x0ffa!] 36945+ A? www.ietf.org. (30)
09:16:50.769351 IP6 (hlim 55, next-header UDP (17) payload length: 115)
2001:4860:4860::8888.53 > 2001:6a8:3080:2:2908:3cb4:bbb4:ae0e.56551: [udp sum ok] 36945 q:
A? www.ietf.org. 3/0/0 www.ietf.org. CNAME www.ietf.org.cdn.cloudflare.net.,
www.ietf.org.cdn.cloudflare.net. A 104.20.1.85, www.ietf.org.cdn.cloudflare.net. A 104.20.0.85
(107)

7. wireshark

8. wireshark

9. DNS spoofing attack
• What is this attack ?
• How to counter it ?

10. Agenda
• Internet applications
• DNS
• Email
• Web
• UDP
• TCP

11. MIME
• Multipurpose Internet Mail Extensions
• Constraints
• must remain compatible with old email servers
• short US-ASCII Lines
• must support non-English text
• must support various formats
• must allow to transmit audio, video, ..

12. MIME (2)
• New header fields
• MIME-Version:
• version of MIME used to encode message
• Content-Description:
• comment describing the content of the message
• Content-Type:
• type of information inside message
• Content-Transfer-Encoding:
• how the message has been encoded
• Content-Id:
• unique identifier for the content

13. MIME: Content-Type
• Content-Type : type/encoding
• type of content
• text, image, video, application
• multipart
• encoding of content
• text/plain , text/html, image/gif, image/jpeg ,
audio/basic, video/mpeg, video/quicktime,
application/octet-stream, application/postscript
• multipart/alternative, multipart/mixed
• attachment

14. Character sets
l How to support rich character sets ?
• Content-Type: text/plain; charset=us-ascii
• Content-Type: text/plain; charset=iso-8859-1
• Character set suitable for Western European
languages, defined by ISO, 8 bits per character
• Content-Type: text/plain; charset=unicode
• Universal character set

15. Content encoding
• How to encode non-text data ?
• Base64
• Base64
• uses ASCII characters A...Z,a...z,0...9, "+" et "/"
• A=0, B=1, C=2, ... +=62 et /=63
• Each character is used to encode 6 bits
• 24 bits from initial message -> 4 ASCII characters
• Special character “=” used for padding

16. Multipart/mixed
Date: Mon, 20 Sep 1999 16:33:16 +0200
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Test
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
preamble, to be ignored
--simple boundary
Content-Type: text/plain; charset=us-ascii
partie 1
--simple boundary
Content-Type: text/plain; charset=us-ascii
partie 2
--simple boundary

17. Agenda
• Internet applications
• DNS
• Email
• Web
• UDP
• TCP

18. HTTP
Client
Server
Request
Method
Header
CRLF
MIME Document
Method
GET
lPOST
l...
Header contains additional information
about request sent by client
Response
Status line
Header
CRLF
MIME Document
Header contains information about server
and optional parameters specific to response
Success or failure
HTTP is a stateless protocol, server does not maintain any state from
one request to another

19. HTTP/1.0
• HTTP 1.0 - non-persistent connection
Client Server
CONNECT.request CONNECT.indication
CONNECT.confirm
CONNECT.response
DATA.request(Request)
DATA.ind(Request)
DATA.req(Response)
DATA.ind(Response)
DISCONNECT.ind
DISCONNECT.req
DISCONNECT.req
DISCONNECT.ind

20. HTTP : Methods
• Methods
• GET
• method used to request a "document" stored on
server
• GET <document> HTTP/1.0
• POST
• method used to send a "document" to a
server
• document is part of the request and encoded as
a MIME document

21. Request headers
• Host: <name>
• Name of the server where the document is stored
• Authorization
• allows to perform access control
• If-Modified-Since: <date>
• server will only send if more recent than date
• Referer: <url>
• URL visited by the client before this request
• User-Agent: <agent>
• client’s browser

22. HTTP : Status line
• Format : Version_HTTP Code Comment
• Success/Failure
• 2xx : Success
• Example : HTTP/1.0 200 OK
• 3xx : Redirection
• 4xx : Client-side error
• 5xx : Server-side error

23. HTTP Response
• Date
• date of the document attached to response
• Server
• Name and version of http server used
• Content-*
• MIME header of the attached document

24. HTTP 1.1
HTTP 1.0
a single TCP connection is used to transmit
a single document (html file, image,...)
HTTP 1.1
uses a single persistent TCP connection
This TCP connection can be used for several
requests and the corresponding responses
the cost of establishing and releasing the TCP
connection is amortised over multiple requests
Although HTTP 1.1 uses a single TCP connection
for multiple requests, HTTP 1.1 remains stateless

25. HTTP 1.1
Client
Server
CONNECT.request CONNECT.indication
CONNECT.confirm CONNECT.response
DISCONNECT.ind
HTTP/1.1 200 OK
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
...
DISCONNECT.req
DISCONNECT.req
DISCONNECT.ind
GET / HTTP1.1
Connection: Keep-Alive
... HTTP/1.1 200 OK
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
GET /images/logo.gif HTTP1.1 ...
Connection: Keep-Alive
...

26. HTTP Authentication
Client
Server
HTTP/1.0 401 Authorization req
WWW authenticate: machin
...
GET / HTTP1.1
...
Browser asks user/password to user
HTTP/1.1 200 OK
...
GET / HTTP1.1
Authorization: User-password
...
GET /images/t.gif HTTP1.1
Authorization: User-password
...
Browser sends user/password in each request

27. HTTP Cookies
Client
Server
HTTP/1.0 200 OK
Set-Cookie: machin
...
GET / HTTP1.1
...
Browser saves cookie
Normal response
HTTP/1.1 200 OK
...
GET /doc HTTP1.1
Cookie: machin
...
GET /images/t.gif HTTP1.1
Cookie: machin
...
Browser sends cookie in all
requests sent to server
Response is function
of URL and cookie

28. Examples
• Wireshark packet traces
• Google chrome network diagnostics

29. Example
curl -v www.ietf.org
* Rebuilt URL to: www.ietf.org/
* Hostname was NOT found in DNS cache
* Trying 2400:cb00:2048:1::6814:155...
* Connected to www.ietf.org (2400:cb00:2048:1::6814:155) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: www.ietf.org
> Accept: */*
>

30. Example
< HTTP/1.1 200 OK
< Date: Tue, 21 Oct 2014 07:31:08 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d90d850d78da8f53eb24ac0bed60aa2231413876667742;
expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.ietf.org; HttpOnly
< Last-Modified: Fri, 10 Oct 2014 22:38:16 GMT
< ETag: W/"8842406-4ac2-50519347abeda"
< Vary: Accept-Encoding
* Server cloudflare-nginx is not blacklisted
< Server: cloudflare-nginx
< CF-RAY: 17cbc0f5613b0c23-AMS
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><!-- InstanceBegin
template="/Templates/GeneralPage.dwt" codeOutsideHTMLIsLocked="false" -->

31. Chrome

32. Agenda
• Internet applications
• DNS
• Email
• Web
• UDP
• TCP

33. Transport layer
Transport Segments Transport
Network Network
Network
Datalink Datalink
Datalink
Physical Physical
Physical
• Objectives
• Improve service provided to applications
• Multiplexing

34. Network service
Network Packets Network Packets
Network
Datalink Datalink
Datalink
Physical Physical
Physical
• Characteristics
• Connectionless
• Unreliable
• Maximum packet size

35. UDP protocol
32 bits
Source Port Destination port
Used to identify the
application that sent this
segment on sending host
8 bytes UDP length UDP Checksum
Payload
Used to identify the
application that will receive
this segment on destination
host
Constraint
Each UDP segment must
fit inside a single IP packet
Checksum computed over the entire
UDP segment and part of the IP
header to detect transmission errors.
0 means that the sender did not
compute a checksum.

36. UDP ports
Request
Client Server
Source port : 1234
Destination port: 5678
Source port : 5678
Destination port: 1234
Response

37. UDP : limitations
• Maximum length of UDP SDUs depends on
maximum size of IP packets
• Unreliable connectionless service
• SDUs can get lost but transmission errors will
be detected
• UDP does not preserve ordering
• UDP does not detect nor prevent duplication

38. Usage of UDP
• Request-response applications
• DNS, RPC, NFS, ..
• Applications with short delay
• Games
• Multimedia transfer
• Voice over IP
• Video over IP

39. Agenda
• Internet applications
• DNS
• Email
• Web
• UDP
• TCP

40. TCP
• Service provided
• Connection-oriented
• Reliable
• No losses, no errors, no duplications
• Bytestream

41. TCP port numbers
Request
Client : C Server : S
Source Port : 1234
Destination Port: 5678
Source Port : 5678
Destination Port: 1234
Response
Established TCP connections on client
Local IP Remote IP Local Port Remote Port
C S 1234 5678
Established TCP connections on server
Local IP Remote IP Local Port Remote Port
S C 5678 1234

42. TCP segment
32 bits
Source port Destination port
THL Reserved Flags
Window
Checksum Urgent pointer
Payload
20 bytes
Sequence number
Optional header extension
Flags :
used to indicate the function of a segment
SYN : used during establishment
FIN : used during connection release
RST : used in case of problems
ACK : if true, means that the Acknowledgement
number inside the segment is valid
Computed over the entire
segment and part of the IP
header
Acknowledgement number
Segment header length

43. Multiple connections
Client: A
Client : B
Server : S
TCP connections on server
IP local IP remote Port local Port remote
S A 80 1234
S A 80 1235
S B 80 1235
TCP connections on host A
IP local IP remote Port local Port remote
A S 1234 80
A S 1235 80
TCP connections on host B
IP local IP remote Port local Port remote
B S 1235 80

44. Three-way handshake
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y)
CONNECT.resp
Initial sequence number (x)
CONNECT.conf
Initial sequence number (y)
SYN(seq=x)
Connection established
Connection established
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1

45. Connection refused
RST+ACK(ack=x+1,seq=0)
DISCONNECT.req
CONNECT.req
DISCONNECT.ind
CONNECT.ind
SYN(seq=x)
Connection refused
A TCP entity should never send a RST segment
upon reception of another RST segment

46. Reliable data transfer
DATA.req ("abcd")
DATA.ind("abcd")
(seq=123,"abcd")
DATA.req ("jkl")
(seq=127,"efg")
(seq=132,"jkl")
DATA.req ("efg")
(ack=127)
(ack=135)
DATA.ind("efghijkl")
DATA.req ("hi")
(seq=130,"hi")

47. Reliable data transfer
(seq=123,"abcd")
(seq=127,"ef")
(seq=123,"abcd")
(seq=127,"ef")
(ack=123)
Retransmission timer
(ack=129)
(ack=129)
"abcdef"
unnecessary
retransmission
Retransmission of all
unacked segments
“ef” placed in buffer

48. Fast retransmit
(seq=120,"xyz")
(seq=123,"abcd")
(ack=123)
(seq=129,"gh")
(seq=131,"ij")
(ack=123)
First duplicate ack
(ack=123)
Second duplicate ack
(ack=123)
Third duplicate ack
(seq=127,"ef")
Out of sequence
Out of sequence
Out of sequence

49. Fast retransmit
(seq=123,"abcd")
(ack=123)
(ack=123)
(ack=123)
(ack=123)
(ack=133)
(seq=123,"abcd")
"abcdefghij"
(seq=127,"ef")
Out of sequence, in buffer
(seq=129,"gh")
Out of sequence, in buffer
(seq=131,"ij")
Out of sequence, in buffer

50. Flow control
(seq=122,"abcd")
(ack=126,rwin=0)
Last_ack=122, swin=100, rwin=4
To transmit : abcdefghijklm
Last_ack=122, swin=96, rwin=0
Last_ack=126, swin=100, rwin=0 (ack=126,rwin=2)
(seq=126,"ef")
(ack=128,rwin=20)
Last_ack=126, swin=100, rwin=2
Last_ack=126, swin=98, rwin=0
Last_ack=128, swin=100, rwin=20
Last_ack=128, swin=93, rwin=13
(seq=128,"ghijklm")
(ack=135,rwin=20)
Last_ack=135, swin=100, rwin=20

51. Connection release
FIN(seq=x)
DISCONNECT.req (A-B)
DISCONNECT.ind(A-B)
ACK(ack=x+1)
DISCONNECT.conf(A-B)
ACK(ack=y+1)
DISCONNECT.req(B-A)
DISCONNECT.conf(A-B)
outgoing connection closed
DISCONNECT.ind(B-A)
FIN(seq=y)
Time WAIT
Maintain state for this
connection during twice MSL
to be able to retransmit ACK
if a segment is received from
the other entity
incoming connection closed
incoming connection closed
outgoing connection closed
State can be removed
Last sent data : x-1
Last sent data : y-1

52. Abrupt release
RST(seq=x)
DISCONNECT.req (abrupt)
DISCONNECT.ind(abrupt)
Connection closed
Connection closed
State can be removed
State can be removed
Last sent data : x