네트워크 애플리케이션 구조
클라이언트/서버 구조
- 웹 애플리케이션과 같이, 항상 켜져있는 서버 호스트가 다른 많은 클라이언트 호스트의 요청을 처리하는 구조
- 클라이언트는 직접 통신하지 않음
- 서버가 고정 IP주소라는 잘 알려진 주소를 가짐
- 하나의 서버 호스트가 클라이언트의 모든 요청을 처리하기 어려울 경우, 데이터 센터 등으로 가상 서버를 생성
P2P 구조
- 항상 켜져있는 기반 서버에 최소 의존 또는 전혀 의존하지 않음
- 간헐적으로 연결된 호스트 쌍이 서로 직접 통신
- 클라이언트-서버 구조와 P2P 요소를 결합한 하이브리드 구조도 존재
- 자가 확장성을 가지며, 비용 효율적
프로세스 간 통신
- 서로 다른 2개의 종단 시스템에서 각각의 프로세스는 메시지 교환을 통해 통신
프로세스 - 네트워크 인터페이스
- 프로세스는 소켓(socket, 호스트의 애플리케이션 레이어와 트랜스포트 레이어 간 인터페이스)을 통해 네트워크로 메시지를 주고받음
- 애플리케이션 개발자는 트랜스포트 계층에는 트랜스포트 프로토콜의 선택과 약간의 매개변수만 통제가 가능
TCP와 UDP
TCP
- 연결 지향형 서비스: 클라이언트와 서버는 전송 제어 정보를 교환하는 핸드셰이크 단계를 거친 후에 연결이 생성되어 양방향 메시지 전달이 가능해지고, 메시지 전송이 끝나면 연결을 끊는다.
- 신뢰적 데이터 전송 서비스
- SSL: 암호화를 제공하지 않는 TCP에 보안성을 갖추기 위해 애플리케이션 레이어에 구현된 암호화 프로토콜
- 혼잡 제어 방식: 인터넷의 전체 성능 향상을 위해 각 연결의 대역폭 조정 및 제한
UDP
- 최소 서비스 모델: 비연결형, 비신 뢰적 데이터 전송 서비스
- 혼잡 제어 방식 미포함
HTTP
- HTTP는 클라이언트 프로그램(웹 브라우저)과 서버 프로그램(웹 서버)으로 구현된다.
- 웹 페이지를 구성하는 각 객체의 URL은 1)해당 객체가 존재하는 서버의 호스트 네임과 2)객체의 경로 이름을 가진다.
- HTTP는 TCP를 기반으로 하며, 브라우저와 서버의 프로세스는 소켓 인터페이스를 통해 TCP 통신을 진행한다.
- HTTP는 상태가 없다(stateless).
HTTP 메시지 포맷
HTTP req 메시지
- request 라인: HTTP req 메시지의 첫 번째 줄이다.
- 메서드 필드(GET, POST, HEAD, PUT, DELETE, etc.)
- GET: URL에 해당하는 객체를 요청한다.
- POST: 사용자가 입력한 form 정보를 전달을 포함한 객체를 요청한다.
- HEAD: GET과 유사하나, 객체는 보내지 않고 HTTP 메시지 res만 요청한다.
- PUT: 웹 서버에 업로드할 객체가 필요한 애플리케이션이 사용한다.
- DELETE: 웹 서버에 있는 객체의 삭제를 요청한다.
- URL 필드
- HTTP 버전 필드
- header 라인: HTTP req 메시지의 나머지 줄이다.
- Host: 객체가 존재하는 호스트 네임이며, 웹 프록시 캐시가 요구하는 정보이다.
- Connection: 지속 연결을 사용할지 여부
- User-agent: 브라우저 타입
- Accept-language: 선호 언어
- entity body: GET에서는 empty 상태이며, POST에서는 사용자가 입력한 form 정보를 포함한다.
HTTP res 메시지
- 초기 상태 라인
- HTTP 버전 필드
- 상태 코드 및 메시지
- 200 OK
- 301 Moved Permanently
- 400 Bad Request
- 404 Not Found
- 505 HTTP Version Not Supported
- header 라인:
- Connection: 클라이언트에게 메시지를 보낸 후 연결을 지속할지 여부
- Date: 서버가 HTTP res를 생성하고 보낸 시간
- Server: 웹 서버 타입(req의 User-agent와 유사)
- Last-Modified: 객체 생성 또는 최근 수정 시간이며, 캐싱 기능에 중요하게 사용된다.
- Content-Length: 객체 크기
- Conent-Type: 객체 타입
- entity body
- HTTP는 stateless하므로, 서버가 사용자를 추적하기 위해 쿠키(cookie)를 사용한다.
- 쿠키는 아래와 같은 4개 요소로 작동한다.
- HTTP res 메시지 쿠키 헤더 라인: 서버는 사용자 식별을 위한 ID를 생성하고 Set-cookie: 헤더에 이를 포함한다.
- 브라우저 쿠키 파일: 브라우저는 이를 자신이 관리하는 쿠키 파일에 저장한다.
- HTTP req 메시지 쿠키 헤더 라인: 브라우저는 쿠키 파일에 현재 사이트에서 발급받은 쿠키가 있을 경우 이를 Cookie: 헤더로 포함하여 req 메시지를 전달한다.
- 서버(사이트) 백엔드 데이터베이스: 쿠키로 식별한 각 사용자의 활동 정보가 저장된다.
웹 캐싱
- 웹 캐시는 프록시 서버라고도 불리며, origin을 대신하여 HTTP req를 처리해줄 수 있는 네트워크 개체이다.
- 이를 위해 자체 저장 디스크를 갖추고 최근 호출된 객체의 사본을 저장한다.
- 브라우저 설정을 통해 모든 HTTP 요청을 웹 캐시를 거치도록 구성할 수 있다.