SlideShare a Scribd company logo
Week 6 
Internet applications 
UDP and TCP
Agenda 
• Internet applications 
• DNS 
• Email 
• Web 
• UDP 
• TCP
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
Examples 
• Wireshark packet traces 
• openDNS resovers 
• 8.8.8.8 
• 2001:4860:4860::8888
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
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)
wireshark
wireshark
DNS spoofing attack 
• What is this attack ? 
• How to counter it ?
Agenda 
• Internet applications 
• DNS 
• Email 
• Web 
• UDP 
• TCP
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, ..
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
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
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
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
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
Agenda 
• Internet applications 
• DNS 
• Email 
• Web 
• UDP 
• TCP
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
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
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
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
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
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
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
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 
...
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
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
Examples 
• Wireshark packet traces 
• Google chrome network diagnostics
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: */* 
>
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" -->
Chrome
Agenda 
• Internet applications 
• DNS 
• Email 
• Web 
• UDP 
• TCP
Transport layer 
Transport Segments Transport 
Network Network 
Network 
Datalink Datalink 
Datalink 
Physical Physical 
Physical 
• Objectives 
• Improve service provided to applications 
• Multiplexing
Network service 
Network Packets Network Packets 
Network 
Datalink Datalink 
Datalink 
Physical Physical 
Physical 
• Characteristics 
• Connectionless 
• Unreliable 
• Maximum packet size
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.
UDP ports 
Request 
Client Server 
Source port : 1234 
Destination port: 5678 
Source port : 5678 
Destination port: 1234 
Response
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
Usage of UDP 
• Request-response applications 
• DNS, RPC, NFS, .. 
• Applications with short delay 
• Games 
• Multimedia transfer 
• Voice over IP 
• Video over IP
Agenda 
• Internet applications 
• DNS 
• Email 
• Web 
• UDP 
• TCP
TCP 
• Service provided 
• Connection-oriented 
• Reliable 
• No losses, no errors, no duplications 
• Bytestream
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
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
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
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
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
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")
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
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
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
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
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
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

More Related Content

PPTX
9 ipv6-routing
PPT
5 sharing-app
PPTX
8 congestion-ipv6
PPTX
Part 5 : Sharing resources, security principles and protocols
PPTX
Part 9 : Congestion control and IPv6
PPTX
Part 4 : reliable transport and sharing resources
PPTX
12 ethernet-wifi
PPTX
4 transport-sharing
9 ipv6-routing
5 sharing-app
8 congestion-ipv6
Part 5 : Sharing resources, security principles and protocols
Part 9 : Congestion control and IPv6
Part 4 : reliable transport and sharing resources
12 ethernet-wifi
4 transport-sharing

What's hot (20)

PPTX
Part 7 : HTTP/2, UDP and TCP
DOCX
Surviving The Stump The Chump Interview Questions
PPTX
10 routing-bgp
PPTX
Part 8 : TCP and Congestion control
DOCX
Network interview questions
PPTX
TCPLS presentation @ietf 109
PPTX
IPv6 Segment Routing : an end-to-end solution ?
PPTX
Future Internet protocols
PPTX
7 tcp-congestion
PPTX
Part 1 : reliable transmission
PPTX
11 bgp-ethernet
PPT
Computer Networking : Principles, Protocols and Practice - lesson 1
PPTX
Beyond TCP: The evolution of Internet transport protocols
PPTX
Making our networking stack truly extensible
PPTX
16 coms 525 tcpip - routing protocols -all
PPTX
Part 2 : reliable transmission and building a network
PDF
Networking Fundamentals: Transport Protocols (TCP and UDP)
PPTX
10 coms 525 tcpip - internet protocol - ip
PPTX
0-RTT TCP converters
PPTX
Multipath TCP
Part 7 : HTTP/2, UDP and TCP
Surviving The Stump The Chump Interview Questions
10 routing-bgp
Part 8 : TCP and Congestion control
Network interview questions
TCPLS presentation @ietf 109
IPv6 Segment Routing : an end-to-end solution ?
Future Internet protocols
7 tcp-congestion
Part 1 : reliable transmission
11 bgp-ethernet
Computer Networking : Principles, Protocols and Practice - lesson 1
Beyond TCP: The evolution of Internet transport protocols
Making our networking stack truly extensible
16 coms 525 tcpip - routing protocols -all
Part 2 : reliable transmission and building a network
Networking Fundamentals: Transport Protocols (TCP and UDP)
10 coms 525 tcpip - internet protocol - ip
0-RTT TCP converters
Multipath TCP
Ad

Viewers also liked (6)

PDF
Beyond TCP: The evolution of Internet transport protocols
PPT
Internet innovation with Multipath TCP
PPTX
Some lessons learned developing OERs over a decade
PPTX
Implementing IPv6 Segment Routing in the Linux kernel
PPT
3 network-transport
PPT
2 reliability-network
Beyond TCP: The evolution of Internet transport protocols
Internet innovation with Multipath TCP
Some lessons learned developing OERs over a decade
Implementing IPv6 Segment Routing in the Linux kernel
3 network-transport
2 reliability-network
Ad

Similar to 6 app-tcp (20)

PPTX
Part 6 : Internet applications
PDF
Computer network (10)
PDF
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
PPTX
An Introduction to HTTP
PPT
HTTP.ppt
PPT
Hypertext Transfer Protocol Hypertext Transfer Protocol
PPT
HTTP.ppt
PPT
HTTP (syper text transfer protocol)(6).ppt
PPT
HTTP_2.ppt
PPT
computer networking
PPTX
Unit 6 : Application Layer
PPTX
CN_Unit V_PPT_15_11_2022 its Computer Networks.pptx
PPT
Http VS. Https
PDF
HTTP colon slash slash: end of the road? @ CakeFest 2013 in San Francisco
PDF
HTTP colon slash slash: the end of the road?
PPTX
Http protocol
PDF
Lec 6(Application Layer)
PDF
Application layer
PDF
HTTPs Strict Transport Security
PDF
HTTP In-depth
Part 6 : Internet applications
Computer network (10)
Angelo van der Sijpt - How well do you know your network stack? - Codemotion ...
An Introduction to HTTP
HTTP.ppt
Hypertext Transfer Protocol Hypertext Transfer Protocol
HTTP.ppt
HTTP (syper text transfer protocol)(6).ppt
HTTP_2.ppt
computer networking
Unit 6 : Application Layer
CN_Unit V_PPT_15_11_2022 its Computer Networks.pptx
Http VS. Https
HTTP colon slash slash: end of the road? @ CakeFest 2013 in San Francisco
HTTP colon slash slash: the end of the road?
Http protocol
Lec 6(Application Layer)
Application layer
HTTPs Strict Transport Security
HTTP In-depth

More from Olivier Bonaventure (20)

PPTX
Part3-reliable.pptx
PPTX
Part10-router.pptx
PPTX
Part1-Intro-Apps.pptx
PPTX
Part9-congestion.pptx
PPTX
Part2-Apps-Security.pptx
PPTX
Part11-lan.pptx
PPTX
Part5-tcp-improvements.pptx
PPTX
Part8-ibgp.pptx
PPTX
Part4-reliable-tcp.pptx
PPTX
Part7-routing.pptx
PPTX
Part6-network-routing.pptx
PPTX
Part1-Intro-Apps.pptx
PPTX
Part2-Apps-Security.pptx
PPTX
Part4-reliable-tcp.pptx
PPTX
Part3-reliable.pptx
PPTX
A personal journey towards more reproducible networking research
PPTX
Part 12 : Local Area Networks
PPTX
Part 11 : Interdomain routing with BGP
PPTX
Part 10 : Routing in IP networks and interdomain routing with BGP
PPTX
Part 3 : building a network and supporting applications
Part3-reliable.pptx
Part10-router.pptx
Part1-Intro-Apps.pptx
Part9-congestion.pptx
Part2-Apps-Security.pptx
Part11-lan.pptx
Part5-tcp-improvements.pptx
Part8-ibgp.pptx
Part4-reliable-tcp.pptx
Part7-routing.pptx
Part6-network-routing.pptx
Part1-Intro-Apps.pptx
Part2-Apps-Security.pptx
Part4-reliable-tcp.pptx
Part3-reliable.pptx
A personal journey towards more reproducible networking research
Part 12 : Local Area Networks
Part 11 : Interdomain routing with BGP
Part 10 : Routing in IP networks and interdomain routing with BGP
Part 3 : building a network and supporting applications

Recently uploaded (20)

PPTX
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
DOCX
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
PPT
Mechanical Engineering MATERIALS Selection
PDF
737-MAX_SRG.pdf student reference guides
PDF
Operating System & Kernel Study Guide-1 - converted.pdf
PPTX
Internet of Things (IOT) - A guide to understanding
PDF
The CXO Playbook 2025 – Future-Ready Strategies for C-Suite Leaders Cerebrai...
PPT
Project quality management in manufacturing
PDF
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
PPTX
Construction Project Organization Group 2.pptx
PDF
TFEC-4-2020-Design-Guide-for-Timber-Roof-Trusses.pdf
PPTX
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
PDF
Well-logging-methods_new................
PPTX
additive manufacturing of ss316l using mig welding
PDF
R24 SURVEYING LAB MANUAL for civil enggi
PDF
PREDICTION OF DIABETES FROM ELECTRONIC HEALTH RECORDS
PDF
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
DOCX
573137875-Attendance-Management-System-original
PPTX
M Tech Sem 1 Civil Engineering Environmental Sciences.pptx
PPTX
Current and future trends in Computer Vision.pptx
Infosys Presentation by1.Riyan Bagwan 2.Samadhan Naiknavare 3.Gaurav Shinde 4...
ASol_English-Language-Literature-Set-1-27-02-2023-converted.docx
Mechanical Engineering MATERIALS Selection
737-MAX_SRG.pdf student reference guides
Operating System & Kernel Study Guide-1 - converted.pdf
Internet of Things (IOT) - A guide to understanding
The CXO Playbook 2025 – Future-Ready Strategies for C-Suite Leaders Cerebrai...
Project quality management in manufacturing
BMEC211 - INTRODUCTION TO MECHATRONICS-1.pdf
Construction Project Organization Group 2.pptx
TFEC-4-2020-Design-Guide-for-Timber-Roof-Trusses.pdf
Engineering Ethics, Safety and Environment [Autosaved] (1).pptx
Well-logging-methods_new................
additive manufacturing of ss316l using mig welding
R24 SURVEYING LAB MANUAL for civil enggi
PREDICTION OF DIABETES FROM ELECTRONIC HEALTH RECORDS
keyrequirementskkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
573137875-Attendance-Management-System-original
M Tech Sem 1 Civil Engineering Environmental Sciences.pptx
Current and future trends in Computer Vision.pptx

6 app-tcp

  • 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)
  • 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" -->
  • 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

Editor's Notes

  • #13: MIME was defined in N. Freed and N. Borenstein. Multipurpose internet mail extensions (MIME) part one: Format of internet message bodies. Request for Comments 2045, Internet Engineering Task Force, November 1996. N. Freed and N. Borenstein. Multipurpose internet mail extensions (MIME) part two: Media types. Request for Comments 2046, Internet Engineering Task Force, November 1996.
  • #18: Exemple de message MIME Received: from loriot.info.fundp.ac.be (loriot.info.fundp.ac.be [138.48.32.96]) by leibniz.info.fundp.ac.be (8.9.1/8.9.1) with SMTP id QAA19679; Mon, 20 Sep 1999 16:37:25 +0200 (MET DST) Message-Id: &amp;lt;3.0.5.32.19990920163316.00866340@info.fundp.ac.be&amp;gt; Date: Mon, 20 Sep 1999 16:33:16 +0200 To: pers-aca, pers-sci From: Gysele HENRARD &amp;lt;ghe@info.fundp.ac.be&amp;gt; Subject: listes Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=&amp;quot;=====================_937830796==_&amp;quot; --=====================_937830796==_ Content-Type: text/plain; charset=&amp;quot;iso-8859-1&amp;quot; Content-Transfer-Encoding: quoted-printable Bonjour, Voici des listes de 1M-1L, 2M-2L et ERASMUS mises =E0 jour ce lundi 20 septembre. Gyselle --=====================_937830796==_ Content-Type: application/octet-stream; name=&amp;quot;1M_99_00.xls&amp;quot;; x-mac-type=&amp;quot;584C5334&amp;quot;; x-mac-creator=&amp;quot;5843454C&amp;quot; ...
  • #21: HTTP 1.0 is defined in : T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol -- HTTP/1.0. Request for Comments 1945, Internet Engineering Task Force, May 1996.
  • #26: HTTP 1.1 is defined in : R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext transfer protocol -- HTTP/1.1. Request for Comments 2616, Internet Engineering Task Force, June 1999.
  • #37: The computation of the UDP checksum is defined in : R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
  • #39: UDP is mainly used for applications where either short messages are exchanged or losses or not a severe problem (either because they can be supported by the application or because they are used in LAN environment where there are almost no losses) Domain Name System, Network File System (NFS), Remote Procedure Call (RPC), jeux Multimedia (conversational) applications such as VoIP or VideooverIP often use UDP. In this case, UDP is often combined with RTP H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.RTP: A Transport Protocol for Real-Time Applications. RFC1889, Jan 1996
  • #44: Urgent pointer is rarely used and will not be described. The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
  • #46: MSL in IP networks : 120 seconds
  • #50: Don’t forget that TCP’s acknowledgements are cumulative.
  • #51: See e.g. RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
  • #54: Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.