웹 요청과 응답
- 수강 : 10/18
웹서비스가 작동하기 위한 수 많은 약속들
- TCP
- 일대일 연결
- 손실시 재전송 요청 -> 신뢰도 높다
- 데이터의 순서와 무결성 보장
- 속도가 상대적으로 느림
- 높은 신뢰도를 요하는 서비스에 적합함
- UDP
- 일대다 연결도 가능
- 정보를 받았는지 확인하지 않고 일방적으로 보냄
- 데이터의 순서와 무결성을 보장하지 않음
- 속도가 상대적으로 빠름
- IPTV, 스트리밍 서비스에 적합함
TCP Handshake
3-way
- SYN (C -> S)
- SYN + ACK (S -> C)
- ACK (S -> C)
4-way
- FIN (C -> S)
- ACK (S -> C)
- FIN (S -> C)
- ACK (C -> S)
HTTP
- Hyper Text Transfer Protocol
- TCP/IP 위에서 전송하는 데이터의 규격에 대한 약속
HTTP 요청/응답의 구조
- 사용자가 브러아주에 URL을 입력한다.
- 브라우저가 요청 메세지를 보낸다.
- 서버가 URL을 프로그램 또는 정적 파일로 연결한다.
- 서버가 응답 메시지를 반환한다.
- 브라우저가 응답 형식에 맞춰 표시한다.
HTTP 특징
- 단방향성
- 서버가 클라이언트로 먼저 요청을 보낼 수는 없음.
- 비연결성
- 연결이 계속 유지되지 않음. 응답이 끝나면 연결을 끊음
- 서버의 자원을 절약하여 경제적으로 서버 운영 가능
- 반대로는 소켓통신이 있음
- 무상태성
- 상태를 가지지 않는다!
- 이를 보와하기 위해 쿠키, 세션, 토큰 등을 사용
HTTP 헤더
- URL
- HTTP 메소드
- GET, POST
- 응답 코드
- status code
- IP 코드
- 응답 헤더
- 컨텐츠 길이, 데이트
- 서버가 어떤 엔진을 사용하는지, 어떤 운영체제에서 들어가는지 확인할 수 있음
- 요청 헤더
- 쿠키가 담겨져서 간다.
- User agent (요청 보낸 브라우저의 프로필이 들어간다.)
-> 서버는 이거에 맞춰서 응답을 보낼 수 있음
HTTP 응답 코드
- 2xx, 3xx : 성공
- 4xx : 클라이언트 오류
- 5xx : 서버 오류
HTTP 캐시
- 응답의 헤더를 통해 컨텐츠의 길이, 캐시의 유효시간, ETag를 전송한다.
API
- 해당 프로그램의 구현을 알지 않아도 프로그램이 제공하는 기능을 쓸 수 있도록 한 인터페이스
REST
- REpresental State Transfer
제약 조건
- 클라이언트와 서버 기능은 완벽히 분리되어야 한다.
- 무상태
- 요청을 통해서 클라이언트의 '상태'를 저장하면 안된다.
- 캐시 처리 가능
- 응답을 캐싱할 수 있어야한다.
- 계층화
- 서버와 클라이언트 사이에 캐시 서버나 로드 밸런서 등의 중간 서버를 둘 수 있다.
클라이언트가 대상 서버에 직접 연결되었는지 중간 서버에 연결되었는지 알 수 없다.
- Code on demand
- 서버는 클라이언트가 직접 실행시킬 수 있는 로직을 전송할 수 있다. ex ) 플래시
- 인터페이스 일관성
- 각각의 요청은 URI 등으로 식별된다. 서버가 가지고 있는 리소스는 클라이온트로의 응답과는 구별된다.
- 클라이언트는 서버로부터 전송받아 가지고 있는 정보만으로 리소스를 변경하거나 삭제할 수 있다.
- 각각의 요청은 처리 방법에 대한 충분한 정보를 담고 있다.
- HATEOAS. 해당 리소스에 대해 할 수 있는 모든 동작에 대한 URI를 제공한다.
참고
