헬린코린이
웹 요청과 응답 본문
Browser란
웹 서버에서 이동하며(navigate) 쌍뱡항으로 통신하고 HTML 문서나 파일을 출력하는
그래픽 사용자 인터페이스 기반의 응용 소프트웨어이다. 웹 브라우저는 대표적인 HTTP사용자 에이전트의 하나이기도 합니다.
즉, 브라우저는 웹 서버에 원하는 정보를 요청을 하고 응답받아 사용자에게 받아진다.
웹(World Wide Web)
당시 빠르게 발전하고 있던 인터넷 그리고 HyperText같은 당시 새롭게 떠오르는 컴퓨터 기술들을
활용하여 이러한 문제점을 해결하고자 했습니다.
그래서 Information Management: A Proposal이라는 제안서의 아이디어를 토대로 오늘날의 웹이 탄생되었습니다.
웹은 정보(자원)의 공유를 목적으로 존재하기 때문에 자연스럽게 수많은 요청과 응답사이클의 연속으로 이루어집니다.
공유과정에 참여하는 주최들을 서버와 클라이언트로 분리할 수 있습니다.
서버는 정보, 자원, 서비스를 제공하는 측, 요청을 받고 응답 하는 측이고
ex) 톰켓, 아파치, ... 등
클라이언트는 정보, 자원, 서비스를 사용하는 측, 요청을 보내는 측이다.
ex) 크롬,사파리,... 등
서버와 클라이언트는 HTTPㅇ라는 규약하의 요청과 응답을 보내야 합니다.
HTTP(HyperTextTransferProtocol)
특징은 단방향성, 비연결성, 무상태성으로 나뉘는데
- 단방향성은 클라이언트가 서버로 요청을 보내고 이에 대한 응답을 받는 단방향적 통신이고
(서버가 클라이언트로 먼저 요청을 보낼 수는 없음)
- 비연결성은 연결이 계속 유지되지 않고 요청에 대한 응답이 끝나면 연결을 끊음
(소켓 통신과 반대되는 특징)
- 무상태성은 클라이언트가 서버와 연결된 상태가 아니기 때문에 기본적으로 상태를 자 지지 않음
(이를 보완하기 위해 쿠키, 세션, 토큰 등을 사용함
HTTP 응답 코드는
2XX 성공, 요청이 정상적으로 이루어졌음
3XX 리다이렉션, 요청을 완료하기 위해 다른 주소로 이동해야 함
4XX 클라이언트 오류, 올바르지 않은 요청
5XX 서버오류, 올바른 요청에 대해 서버의 문제로 응답 불가능합니다.
REST(REpresental State Transfer)
일종의 Http의 디자인 패턴이라고 봐도 될 것 같습니다.
REST에는 6가지 제약조건이 있는데요
1. 클라이언트-서버
(클라이언트와 서버의 기능은 완벽히 분리되어야 한다.)
2. 무상태(Stateless)
(요청을 통해 클라이언트의 '상태'를 서버에 저장해선 안 된다. 대신 캐니사 JWT(Json Web Token) 등을 이용해야 한다.)
3. 캐시 처리 가능(Cacheable)
(클라이언트는 응답을 캐싱할 수 있어야 한다. 이는 클라이언트가 같은 자료를 중복 요청하는 것을 막아 서버의 부담을 줄여줄 수 있다.)
4. 계층화(Layered System)
(서버와 클라이언트 사이에 캐시 서버나 로드 밸런서 등의 중간 서버를 들 수 있다.
클라이언트는 대상 서버에 직접 연결되었는지, 혹은 중간 서버에 연결되었는지 알 수 없다.)
5. Code on demand
(서버는 클라이언트가 직접 실행시킬 수 있는 로직을 전송할 수 있다.)
6. 인터페이스 일관성(Uniform Interface)
- 각각의 요청은 URI 등으로 식별된다. 서버가 가지고 있는 리소스는 클라이언트로의 응답과는 구별된다.
- 클라이언트는 서버러부터 전송받아 가지고 있는 정보만으로 리소스를 변경하거나 삭제할 수 있다.
- 각각의 요청은 처리 방법에 대한 충분한 정보를 담고 있다.
예를 들어 'GET/board/1'이라는 요청만으로 '게시판의 1번 게시글을 읽는다.'라는 의미 전달이 된다.
- HATEOAS. 해당 리소스에 대해 할 수 있는 모든 동작에 대한 URI를 제공합니다.
요청을 보내는 방법은 URL을 이용한다.
URL이란
URL을 해석해 보겠다
http://localhost:8080/index.html? key=valued이 있다고 가정해 보자
http는 프로토콜(scheme)이고
localhost는 Domain,
8080은 포트번호,
index.html은 파일의 위치 / 요청 Path이고
? key=value는 쿼리스트링의 구조로 되어있습니다.
Http method는 URL로 특정한 자원을 어떻게 할 것인지 정의합니다.
GET - 서버의 리소스를 조회하고자 할 때(READ) C
POST - 서버의 리소스를 생성하고자 할 때 (CREATE) R
PUT - 서버의 리소스를 수정할 때 (UPDATE) U
DELETE - 서버의 리소스를 삭제할 때 (DELETE) D
HEAD - GET과 동일하나, 서비에서 Body를 빼고 HEAD로만 응답(리소스 확인의 용도)
PATCH - 리소스의 부분만을 수정할 때
TRACE - 리소스의 경로를 따라 메시지 loop-back 테스트를 실행
CONNECT - 리소스로 식별되는 서버로의 터널을 맺을 때
domain vs host
domain: 한 네트워크(서비스)를 대표하는 이름
host: 네트워크에서 고유하게 식별하는 기기(컴퓨터, 파일서버, 복사기, 모뎀 등)의 이름
URL vs URL
URL: 한 리소스에 대한 구체적인 위치 서술
URN: 한 리소스에 대한 리소스의 위치에 영향을 받지 않는 이름
TCP vs UDP
TCP
장점으로는
- 일대일 연결만 가능
- 손실되면 재전송 요청을 하므로 신뢰도가 높음
- 데이터의 순서와 무결성이 보장됨
- 높은 신뢰도를 요하는 서비스에 적합합니다.
- 속도가 상대적으로 느림
UDP
- 일대다 연결도 가능
- 정보를 받았는지 확인치 않고 일반적으로 보냄
- 데이터의 순서와 무결성을 보장하지 않음
- 속도가 상대적으로 빠름
- IPTV, 스트리밍 서비스에 적합