Web page의 구성 요소
웹 페이지는 여러 개의 객체(objects)로 구성됨
이 객체들은 서로 다른 웹 서버에 저장될 수도 있음
- 객체의 예시 : HTML, JPEG, Java Script
Web page의 구조
웹 페이지는 기본 HTML을 포함하고,
HTML 파일은 여러 참조 객체를 가짐
- 각각의 객체는 url로 접근 가능
1. HTTP 개요
: HyperText Transfer Protocol
Web의 응용 계층 프로토콜(application layer protocol)로,
브라우저와 웹 서버 간의 데이터 요청/응답 관리
Client/Server Model
Client
웹 브라우저 역할(ex. Safari)로, 요청을 보냄
(받은 웹 객체를 화면에 받고 표시)
Server
웹 서버 역할(ex. Apache)로, 클라이언트의 요청을 받음
(HTTP 응답으로 웹 객체를 전송함)
Client ↔ Server 통신 흐름
-
HTTP request : 사용자가 웹 브라우저를 통해 요청 보냄
-
HTTP response : 웹 서버가 해당 요청을 처리 후, 응답 데이터를 보냄
(ex. HTMl 문서, 이미지, 웹 객체)
TCP와 HTTP
HTTP는 Transport layer에서 TCP 사용
1) Client가 Server의 port로 TCP 연결을 생성 (소켓 생성)
2) Server가 Client의 TCP 연결을 수락
3) 브라우저(HTTP Client) ↔ 웹 서버 간 HTTP 메시지 교환
(애플리케이션 계층 메시지)
4) 통신 종료 시 TCP 연결도 종료
HTTP는 stateless
Server는 Client의 과거 요청 정보를 저장하지 않음
-> HTTP 요청은 독립적이고, 이전 요청과 무관
State를 유지하는 프로토콜은 어려움
(히스토리를 기억 / 동기화 -> 복잡성 증가)
2. HTTP 연결 방식
Non-persistent HTTP
하나의 HTTP 객체를 전송할 때마다 새로운 TCP 연결 생성
1) TCP 연결 열기
2) 하나의 객체(object) 전송
3) TCP 연결 닫기
- 여러 개의 객체를 다운로드할 경우, 매번 연결 새로하고 닫아야함
(객체가 많다면 비효율적)
Non-persistent HTTP Example
사용자가 요청한 url이 다음과 같을 경우
www.someSchool.edu/someDepartment/home.index
(텍스트 + 10개의 JPEG 이미지 포함)
1a. 클라이언트 측 작업
HTTP 클라이언트가 port=80으로 TCP 연결 요청
1b. 서버 측 작업
서버는 port=80에서 연결 요청을 수신 대기하다가, 수락
2. 요청 메시지 전송
클라이언트는 연결된 소켓에 HTTP request message 전송 (url 정보 포함)
/someDepartment/home.index3. 응답 메시지 전송
서버는 요청을 처리하여 HTTP response message 생성 (요청된 객체 포함, html)
소켓을 통해 클라이언트에게 전송
- 이 모든 과정은 하나의 객체만 처리하고 끝남
(10개의 이미지라면 10번 반복 요청)
4. HTTP 서버가 TCP 연결 종료
서버가 요청된 객체를 전송하면 TCP 연결을 즉시 닫음
5. 클라이언트가 응답 수신
클라이언트가 HTML이 담긴 HTTP response message를 수신
HTML을 파싱(parsing)
→ 내부에 10개의 이미지가 포함된 것 확인
→ 다시 TCP 연결해야 되겠다는 생각을 함
6. 반복 동작
10개의 객체(이미지)를 받기 위해, 1~5단계 반복
(이미지마다 TCP 연결 생성)
Persistent HTTP
한 번 TCP 연결하면, 여러 개의 객체 연속적으로 전송 가능
1) TCP 연결 열기
2) 여러 객체 전송
3) 마지막에 TCP 연결 닫기
- 클라이언트-서버 간 효율적인 통신, 성능 향상
RTT (Round-Trip Time)
클라이언트가 서버로 작은 패킷을 보낼 때,
서버로부터 응답이 돌아오기까지 걸리는 시간
HTTP response time
- TCP 연결 설정 시간 : 1RTT
- 클라이언트가 HTTP 요청 전송 : 1 RTT
- 파일 전송 시간 : 하나의 객체를 보내는데 실제 걸리는 시간
Non-persistent HTTP의 문제점
- 객체 1개당 2 RTT 필요
(연결 설정 + 요청/응답 전달) - TCP 연결마다 OS 오버헤드 발생
(연결/해제 반복으로 성능 저하) - 브라우저는 여러 TCP 연결을 병렬로 열어 처리
(병렬 연결로 속도는 높이지만 리소스 낭비)
Persistent HTTP (HTTP 1.1)의 개선점
- 서버가 응답 후에도 TCP 연결을 유지
(다시 연결할 필요 x) - 동일한 연결을 통해 여러 HTTP 메시지 교환
(모든 객체 요청 가능) - 클라이언트는 참조 객체 발견 즉시 요청 전송 가능
(모든 객체를 받는데 1 RTT면 충분 → 지연 시간 최소화)
3. HTTP 메시지 형식
Request message (요청 메시지)
ASCII (사람이 읽을 수 있는 문자 형식)로 구성
(바이너리 x)
1. Request line (요청 줄)
GET /index.html HTTP/1.12. Header lines (헤더 줄)
클라이언트가 서버에 추가 정보 제공
- 각각의 줄은 key: value 형태
3. 빈 줄 (\r\n)
헤더의 끝을 나타냄 (carriage return + line feed)
(이 줄 이후에 메시지 body가 올 수 있음, POST 요청 시)
HTTP Request Methods
POST method
서버 쪽에 데이터를 새로 등록하거나 처리 요청할 때 사용
- 주로 form input 전송 시 사용됨
- 사용자가 입력한 데이터는 메시지 body에 담겨 전송됨
GET method
데이터를 서버에 요청할 때 사용
- 데이터는 URL 끝에 붙어 전송됨
- 빠르고 간단하지만 보안에 취약(url 정보 노출)
HEAD method
헤더만 요청할 때 사용
- GET과 비슷하지만, 본문(body)은 반환되지 않음
PUT method
서버에 파일 또는 객체 업로드할 때 사용
- 기존 리소스를 완전히 덮어씀
- 보통 POST보다 정확한 위치(URL)에 데이터를 저장하고 싶을 때 사용
Response Message (응답 메시지)
1. Status Line (상태 라인)
(사용 중인 HTTP 버전 / 상태 코드 / 의미 설명)
HTTP/1.1 200 OK2. Header lines (헤더 줄)
응답에 대한 메타 데이터 포함
- 헤더 줄 끝에 (\r\n) 존재, 그 후 종료
3. Data (본문)
실제 클라이언트가 요청한 객체
헤더 다음에 위치하며, 아래와 같은 형태로 시작
data data data data data ... HTTP Response Status Codes (상태 코드)
- 200 OK
요청 성공(정상 처리됨)
(요청한 리소스는 메시지 본문에 포함) - 301 Moved Permanently
요청한 리소스의 위치가 영구적으로 변경됨
(새 위치는 헤더의 Location: 필드에 명시됨) - 400 Bad Request
클라이언트가 잘못된 요청을 보냄(구문오류)
(서버가 요청을 이해 X) - 404 Not Found
요청한 리소스가 서버에 존재 X - 505 HTTP Version Not Supported
서버가 지원하지 않는 HTTP 버전으로 요청을 받음
