Tcp

2.3 인터넷 전자메일 인터넷 메일 시스템의 상위 요소에는 다음 3가지가 있다. 사용자 에이전트(user agent) 사용자의 메시지 읽기, 전달, 저장, 구성을 담당 ex) 지메일, 마이크로소프트 아웃룩, 스파트몬용 지메일 앱 메일 서버(mail server) 각 수신자는 메일 서버 안에 **메일박스(mailbox)**를 갖고 있다. 메일박스는 수신한 메시지를 유지하고 관리한다. 송신자의 사용자 에이전트 → 송신자의 메일 서버 → 송신자의 메일 서버의 메시지 큐 → 수신자의 메일서버 → 수신자의 메일 서버 내 메일박스 수신자의 서버 고장으로 전달할 수 없으면 메시지를 **메시지 큐(message queue)**에 보관하고 나중에 전달을 재시도한다. SMTP(Simple Mail Transfer Protocol) 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜 TCP의 신뢰적인 데이터 전송 서비스를 이용 송신자의 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있음. 메일 서버가 송신할 때 : SMTP의 클라이언트로 동작 메일 서버가 수신할 때 : SMTP의 서버로 동작 2.3.1 SMTP A가 B에게 메일을 보내는 과정 A는 네이버의 전자메일 사용자 에이전트에게 B의 전자메일 주소(B@gmail.com)를 제공하고 메시지를 작성하여 메시지를 보내라고 명령한다. A의 사용자 에이전트(네이버)는 메시지를 A의 메일 서버에게 보내고 그 메시지는 서버에서 메시지 큐에 들어간다. A의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에서 메시지를 확인한다. 이후 B의 메일 서버에서 수행되는 SMTP 서버에게 TCP 연결을 설정한다. 이때 포트는 25. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 A의 메시지를 TCP 연결로 보낸다. B의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 이 메시지는 B의 메일 서버의 메일박스에 저장된다. B은 사용자 에이전트를 이용해 그 메시지를 읽는다. A와 B의 메일 서버가 물리적으로 거리가 멀더라도, 중간 메일 서버는 사용하지 않는다. 따라서 B의 서버가 죽어 있으면 전달하지 못한다. 이 떄, A 서버의 메시지 큐에 두고 지속적으로 재발송한다. 일정시간이 지나면, 폐기하고 A에게 발송이 실패했음을 알린다. 두 서버의 TCP 연결이 설정되면, SMTP의 서버와 클라이언트는 애플리케이션 계층 핸드셰이킹을 수행한다. 핸드셰이킹에서 서로에 대한 정보를 알게 되는 것처럼, 이때 클라이언트는 서버에게 두 사람(송신자와 수신자)의 전자메일 주소를 제공한다. 2.3.2 메일 메시지 포맷 우편을 보낼때, 편지 봉투에는 여러 정보가 담기게 된다(발신자, 수신자 등) 전자 메일에서는 메시지 몸체 앞에 있는 헤더에 담긴다. 2.3.3 메일 접속 프로토콜 메일 서버가 개인의 로컬호스트에 있다면, 항상 메일을 받기 위해 서버가 켜져있어야 한다. 따라서, 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다. 즉, 메일 서버는 보통 사용자들과 공유한다. 송신자의 사용자 에이전트는 메일 서버를 통해 수신자의 메일 서버로 메시지를 전송한다. 왜 송신자의 사용자 에이전트가 직접 수신자의 메일 서버로 메시지를 전송하지 않을까? 송신자의 사용자 에이전트는 수신자의 메일 서버에 도달할 수 없기 때문 이유는 보안 문제, SMTP의 규약, 스팸 방지, 신뢰성 보장 등 다양하다. 수신자의 사용자 에이전트는 받은 메시지를 보기 위해 SMTP를 사용할 수 없다. SMTP는 push지만 메시지는 pull 해야 하기 때문 메시지를 받는 방법 HTTP를 통해 요청 인터넷 메일 접근 프로토콜(Internet Mail Access Protocol, IMAP) 사용 이 둘 모두 메일 서버에 의해 유지되는 폴더를 관리하게 된다.

2.2 웹과 HTTP(1) 2.2.1 HTTP 개요 웹의 애플리케이션 계층 프로토콜인 **HTTP(HyperText Transfer Protocol)**는 웹의 중심이다. **웹 페이지(Web page, 문서)**는 객체(object)들로 구성된다. **객체(object)**는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, 자바스크립트, CCS 스타일 시트 파일, 비디오 클립 등)이다. 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다. 각 URL은 2개의 요소를 갖고 있다. 객체를 갖고 있는 서버의 호스트 이름 객체의 경로 이름 **웹 브라우저(Web browser)**는 HTTP의 클라이언트 측을 구현하기 떄문에 웹의 관점에서 클라이언트와 브라우저는 혼용된다. HTTP는 TCP를 전송 프로토콜로 사용한다. 과정 HTTP 클라이언트가 먼저 서버에 TCP 연결을 시작 브라우저와 서버 프로세스는 각자의 소켓 인터페이스를 통해 TCP로 접속. 소켓 인터페이스는 각 프로세스와 TCP 연결 사이에서의 출입구다. 서버와 클라이언트는 메시지를 소켓 인터페이스에게 보낸다. 이후 부터는 TCP의 몫이다. HTTP는 **비상태 프로토콜(stateless protocol)**이다. 클라이언트에 대한 정보를 유지하지 않기 떄문이다. 2.2.2 비지속 연결과 지속 연결 클라이언트-서버 상호작용이 TCP상에서 발생할 때, 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지면 비지속 연결(non-persistent connection) 모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내지면 지속 연결(persistent connection) HTTP/1.0가 디폴트 모드로 지속 연결을 사용하지만 HTTP 클라이언트와 서버는 비지속연결을 사용하도록 설정될 수 있다. 비지속 연결 HTTP 클라이언트가 서버에게 URL을 통해 html 파일을 요청한다고 가정해보자. HTML 파일은 여러 개의 참조 객체 이미지를 가진다. HTTP 클라이언트는 HTTP 기본 포트 번호 80을 통해 서버로 TCP 연결을 시도한다. 그 결과 클라이언트와 서버는 각각 소켓을 가진다. 클라이언트가 자신의 소켓을 통해 HTTP 요청 메시지를 보낸다. 이 요청에는 필요한 html의 경로 이름을 포함한다. 서버는 소켓으로 요청 메시지를 받고 필요한 html 객체를 추출한다. 응답 메시지에 객체를 캡슐화하고 소켓을 통해 클라이언트로 보낸다. HTTP 서버는 TCP에게 TCP 연결을 끊으라고 한다(하지만 실제로는 클라이언트가 응답을 올바로 받을 때까지 끊지 않는다). 클라이언트가 응답 메시지를 받으면 TCP 연결이 중단된다. 필요한 참조 객체(이미지) 10개를 가져오기 위해 각각의 객체에 대한 TCP 연결이 시작된다(1~4 반복). 비지속 연결에선 총 11개의 TCP 연결이 발생한다. 순차적으로 하지 않고 동시 연결(동시에 11개의 연결을 구성하여 각각 처리)로 응답 시간을 줄일 수 있다. 세 방향 핸드셰이크(three-way handshake) SYN(Synchronize) : 클라이언트가 서버에 연결을 요청하는 메시지를 보냄 SYN-ACK(Synchronize-Acknowledment) : 서버가 클라이언트의 연결 요청을 수락하고, 클라이언테에게 확인 응답을 보냄 ACK(Acknowledgment) : 클라이언트가 서버의 확인 응답을 받고, 다시 서버에 확인 메시지를 보내 연결을 완료한다. RTT(round-trip time) : 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 돌아오는 데 걸리는 시간 세 방향 핸드셰이크 중 2단계가 완료될때 까지의 시간이 RTT다. ACK는 2단계가 완료된 후 요청 메시지를 보낼 때 같이 보낸다. 서버에 요청을 보낼 떄는 (TCP 연결 + 요청)이 필요하다. 따라서 서버의 응답시간은 (2RTT + 파일 전송 시간)이다. 지속 연결 HTTP 비지속 연결의 단점 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 함. 이를 위해 필요한 TCP 버퍼는 서버에게 부담이 될 수 있음. 응답시간 (2 RTT) 지속 연결은 하나의 지속 TCP 연결로 여러 웹페이지와 관련 객체를 통신할 수 있다. 파이프라이닝(pipelining) : 각 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있음. HTTP 서버는 타임아웃 기간동안 사용되지 않으면 연결을 닫기 떄문에, HTTP 디폴트 모드는 파이프라이닝을 이용해 지속 연결한다.

네트워크 애플리케이션 : 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램 웹 애플리케이션에는 서버와 클라어인트라는 두 가지 프로그램이 있다. 클라이언트 : 사용자의 호스트에서 실행되는 브라우저 프로그램 웹 서버 호스트에서 실행되는 웹 서버 프로그램 새로운 애플리케이션을 개발할 때, 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다. 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않는 대신 네트워크 계층 및 그 하위 계층에서 기능한다. 종단 시스템에서만 애플리케이션 소프,트웨어가 존재한다. 2.1.1 네트워크 애플리케이션 구조 애플리케이션 구조는 네트워크 구조(ex. 1.5장에 나온 프로토콜 스택)와 다르다. 개발자 관점에서 네트워크 구조 : 고정되어 있고 해당 애플리케이션에 특정 서비스 집합을 제공 애플리케이션 구조(application architecture) : 개발자가 설계하며 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 알려줌. 최근 가장 많이 사용하는 애플리케이션 구조가 현대 네트워크 애플리케이션에서 사용되는 “클라이언트-서버” 구조와 P2P 구조 클라이언트-서버 구조(client-server architecture) 서버(server) : 항상 동작하고 있는 호스트 클라이언트(client) : 서버에 서비스 요청을 보냄 이 구조에서, 클라이언트는 서로 직접적으로 통신하지 않는다. 서버는 고정 IP 주소를 갖는다. 클라이언트의 요청이 많을 경우 단일 서버 호스트가 모든 요청을 처리하긴 힘들다. 많은 수의 호스트를 갖춘 **데이터 센터(data center)**가 강력한 가상의 서버를 생성하는 역할을 함. P2P 구조 항상 켜져있는 인프라스트럭처 서버에 최소로 의존하거나 의존하지 않음 대신 **피어(peer)**라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신 피어(peer) : 서비스 제공자(service provider)가 소유하지 않고 사용자들이 제어하는 데스크톱과 랩톱 한 엔드시스템이 서버 역할을 해준다. 토렌트가 대표적인 P2P 구조 P2P구조는 **자가 확장성(self-scalability)**이 있다. 각 피어들이 파일을 요구함으로써 작업 부하를 만들어낸다. 하지만 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가함. 토렌트에서 다운로드 받고 업로딩하는 사람이 많을 수록 그 파일은 다운로드 속도가 빨라지는데, 이유가 바로 이것이다. 서버 인프라스트럭처와 서버 대역폭이 필요하지 않아 비용 효율적이다. 보안, 성능, 신뢰성이 단점이다. 2.1.2 프로세스 간 통신 운영체제 용어에서 실제 통신하는 것은 프로그램이 아니라 **프로세스(process)**다. 프로세스(process) 종단 시스템에서 실행되는 프로그램 통신 프로세스가 같은 종단 시스템에서 실행될 때 그들은 서로 프로세스 간에 통신한다. 프로세스 간의 통신을 위한 규칙은 종단 시스템의 운영체제에 의해 좌우된다. 여기서 다룰 통신은 같은 호스트에서 프로세스가 통신하는 방법이 아닌, 다른 호스트에서 실행되어 통신할 때이다. 2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지(message) 교환으로 통신한다. 송신 프로세스 : 메시지를 만들어서 네트워크를 보낸다. 수신 프로세스 : 메시지를 받고 역으로 메시지를 보내 응답한다. 클라이언트와 서버 프로세스 네트워크 애플리케이션 : 서로 메시지를 보내는 두 프로세스로 구성 ...