%% Slides for dissertation proposal defense
%% $Id: proposal-slides.tex,v 1.3 2008/07/03 02:04:25 dtwright Exp $

\documentclass{beamer}

\usepackage{beamerthemesplit}
\usepackage{graphicx}

\title{Introduction to HTTP and network services}
\author{Dan Wright}
\date{\today}

\begin{document}

\frame{\titlepage}

\section[Outline]{}
\frame{\tableofcontents}

\section{Network services architecture}
\frame{
	\huge{Network services architecture}
}
\frame{
  \frametitle{The client-server model}
  \includegraphics[scale=0.28]{intarnets.png} \\

  Most Internet services built using this model. The client may be
  any computer running client software (e.g., a web browser), and the server
  may be any computer running server software (e.g., a web server).
}
\frame{
  \frametitle{Layered architecture}
  \includegraphics[scale=0.31]{ruswp_diag2.png} \\
  \vfill
  {\tiny Image from http://www.theshulers.com/whitepapers/internet\_whitepaper/}
}
\frame{
  \frametitle{Addressing}
  \begin{itemize}
  \item Every computer (client, server, mobile device, etc.) on the public
        Internet has a unique IP address 
  \item Every network service runs on a standard port; this is what allows
        the client to contact services running on some unfamiliar server
  \item The combination of IP address + port number uniquely identifies a
        particular service on a particular machine
  \item Some common examples: SSH: 22, HTTP: 80, HTTPS: 443, SMTP: 25
  \end{itemize}
}
\frame{
  \frametitle{Addressing cont'd.}
  \begin{itemize}
  \item A very common network configuration has a number of IP devices 
        ``hidden'' behind a firewall device that routes their traffic so 
        that it all {\it appears} to come from a single address -- this 
        is how home wireless routers work, for example
  \item How does this potentially break the client/server model?
  \end{itemize}
}

\section{The HTTP protocol}
\frame{
	\huge{The HTTP protocol}
}
\frame{
  \frametitle{The basics}
  \begin{itemize}
  \item HTTP is a simple, text-based protocol designed to efficiently transfer 
        the objects needed for rendering HTML hypertext documents
  \item Most other Internet application protocols are text-based (e.g., SMTP,
        IMAP, POP, and NNTP); this simplifies implementation and debugging 
  \end{itemize}
}
\frame{
  \frametitle{The details}
  \begin{itemize}
  \item Unlike most other protocols, HTTP is connection-oriented; that is,
        it is designed to have each connection serve a single transaction, and
        then close (though note that HTTP 1.1 allows multiple transactions per
        connection)
  \item HTTP can be used to serve any data, not just HTML documents; examples
        include images, PDF files, Flash content, and any number of other file
        data types
  \item HTTP is essentially a data encapsulation protocol -- it provides a
        minimal framework for a client to request and receive data, with as
        little overhead as possible
  \end{itemize}
}

\frame{
  \frametitle{Security concerns}
  \begin{itemize}
  \item Note the security implications of a plain text protocol: anyone who
        can see your traffic with a remote server can see exactly what you are
        doing -- this includes passwords and any other sensitive information
  \item This concern is not unique to HTTP; it also applies to Telnet, SMTP,
        and any other of the plain text protocols
  \item The most common way to address this problem is with SSL, an
        application-level encryption wrapper
  \end{itemize}
}
\frame{
  \frametitle{SSL/TLS}
  \begin{itemize}
  \item Secure Sockets Layer / Transport Layer Security
  \item All ``secure'' web traffic is carried over SSL
  \item The security provided by SSL is of two distinct, and separate, types:
  \begin{itemize}
  \item Identity verification: ``proof'' that the remote server is who they
        claim to be via public-key certificates
  \item Transport encryption: wrapping HTTP traffic in robust encryption so
        sensitive data (like passwords or credit card numbers) can't be 
        grabbed off the wire by a 3rd party
  \end{itemize}
  \item Note that while this protocol covers both, these are actually {\it
        separate} security concerns
  \end{itemize}
}

\section{An example web session}
\frame{
	\huge{An example web session}
}
\frame{
  \frametitle{URL parsing}
  \includegraphics[scale=0.38]{url.png} \\
}
\frame{
  \frametitle{DNS lookup}
  \includegraphics[scale=0.34]{dns.png} \\
}
\frame{
  \frametitle{Document retrieval, parsing, \& rendering}
  {\tt GET /search?q=test HTTP/1.1} \\
  {\tt Connection: close} \\
  ~\\
  \includegraphics[scale=0.32]{screen.png} \\
}

\frame{
  \begin{itemize}
  \item The process of fetching a displaying a web page is a complex,
        multi-step process, potentially involving dozens of network
        transactions and several remote servers 
  \item Thanks to the design of web client software and the architecture of 
        Internet protocols, this complexity is almost completely hidden from
        end users
  \end{itemize}
}

\frame{
}

\end{document}