- 웹 서비스가 작동하기 위한 수많은 약속들
➡ 기반이 되는 부분 = "데이터를 주고받는 약속"
- TCP
- UDP
TCP
- 전화에 비유할 수 있음
- 일대일 연결만 가능
- 손상되면 재전송 요청을 하므로 신뢰도가 높음
- 데이터의 순서와 무결성이 보장됨
- 속도가 상대적으로 느림
- 높은 신뢰도를 요하는 서비스에 적합
① 송신측에서 수신측에게 받을 준비가 되었는지 물어봄
② 수신측이 응답을 하면 데이터를 보냄
* 데이터 : 전체 데이터를 패킷이라는 아주 작은 단위로 나누어 보냄
③ 패킷 하나를 보낸 다음에 잘 받았는지 물어봄
④ 잘 받았다는 응답이 와야 패킷 한 개를 보내는 작업이 종료됨
➡ 이를 여러번 반복
TCP Handshake
3-way
- 클라이언트와 서버 연결시 총 3번 악수하여 연결이 잘 수립되었는지 확인
4-way
- 클라이언트와 서버 연결 해제시 4-way 를 이용
- 클라이언트가 먼저 연결을 끊겠다고 보내면 서버가 알겠다고 보냄
- 이를 총 4번 반복
UDP
- 라디오에 비유할 수 있음
- 일대다 연결도 가능
- 정보를 받았는지 확인하지 않고 일방적으로 보냄
- 데이터의 순서와 무결성을 보장하지 않음
- 속도가 상대적으로 빠름
- IPTV, 스트리밍 서비스에 적합
① 한 번 보냈다면 무조건 다 보냄
➡ 중간에 손실이 나더라도 알 수 없음
HTTP
- HyperText Transfer Protocol
- 하이퍼텍스트 전송 규약
- TCP/IP 위에서 전송하는 데이터와 규격에 대한 약속
== 웹 요청과 응답에 관한 클라이언트와 서버 사이의 규약 (약속)
HTTP 요청 / 응답의 구조
① 사용자가 브라우저에서 url을 입력하거나 버튼 클릭 등을통해 명령을 내림
② 브라우저가 요청 메세지로 바꾸어 서버로 전송
③ 서버가 URL을 프로그램을 실행하는 컨트롤러로 전송을 허거나 파일을 찾음
④ 응답 메세지의 바디에 이 프로그램의 실행결과나 정적 파일을 담아 반환
⑤ 브러우저가 응답을 포맷에 맞춰 표시하는 역할을 수행
HTTP의 특징
- 단방향성
- 클라이언트가 서버로 요청을 보내고 이에 대한 응답을 받는 단방향적 통신
- 요청 응답이 한 세트
- 반드시 클라이언트가 서버로 먼저 요청을 보내야 함
- 서버가 클라이언트로 먼저 요청을 보낼 수 없음
- 비연결성
- 연결이 계속 유지되지 않고 요청에 대한 응답이 끝나면 연결을 끊음
- 다음 요청은 새로운 연결을 통해 이루어짐
- 서버의 자원을 절약하여 좀 더 경제적으로 서버를 운영할 수 있음
- 소켓 통신과 반대되는 특징
* 소켓통신 : 연결이 쭉 유지됨 - 영상 채팅 등에 많이 이용됨 - 단점 : 매번 모든 요청에 대해 새로운 연결/해제 과정을 거치므로 네트워크 비용측면에서 비효율적
- 보완책 : HTTP/1.1 Keep-Alive (서버와 클라이언트 사이에서 통신이 없어도 지정된 시간동안 연결을 유지하는 기능)
- 무상태성
- 클라이언트가 서버와 연결된 상태가 아니기 때문에 기본적으로 상태를 가지지 않음
- 서버와 클라이언트는 하나의 요청이 진행되는 동안만 서로를 인지
- 이를 보완하기 위해 쿠키, 세션, 토큰 등을 사용
- 단점 : 클라이언트 인증(로그인)이 필요한 서비스에서 불편함
- 보완책 : 쿠키, 세션, 토큰 (OAuth, JWT)
HTTP Header
General (일반)
- URL
- HTTP 메소드 : GET
- 응답 코드 : 200
- 원격 주소 : 어떤 IP 주소를 요청 받는지
응답 헤더
- 요청을 바디와 함게 보낸 다음 응답했을 때 바디와 함께 돌아오는 헤더
- content-length : 컨텐츠 길이가 얼마인지
- date : 언제 왔는지
- server : 서버가 어떤 engine을 사용하는지 / 어떤 운영체제에서 돌아가는지
요청헤더
- 처음 요청이 갈 때는 브라우저가 요청헤더를 잡아서 보냄
- User-Agent : 요청을 보낸 브라우저의 프로필이 들어감 ➡ 서버는 이에 맞춰 응답을 보냄
EX) 어떤 브라우저인지 / 어떤 운영체제인지
EX) 프로그램 설치 페이지에서 OS에 따라 버튼이 알맞게 나타나는 것
HTTP 응답 코드
- HTTP Status Code (응답 코드, 상태코드)
- 클라이언트의 요청에 대해서 서버는 요청에 대한 처리 상태를 숫자 코드로 반환
1XX
- 정보
- 요청을 받았으며 프로세스를 계속함
2XX
- 성공
- 요청이 정상적으로 이루어졌음
- 200 OK
- 201 Created
- 202 Accepted
- 204 No Content
3XX
- 리다이렉션
- 요청을 완료하기 위해 다른 주소로 이동해야 함
- 307 Temporary Redirect : 임시
- 308 Permanent Redirect : 영구
4XX
- 클라이언트 오류
- 올바르지 않은 요청
- 400 Bad Request
- 403 Forbidden
- 404 Not Found
5XX
- 서버 오류
- 올바른 요청에 대해 서버의 문제로 응답 불가능함
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Temporarily Unavailable
HTTP 캐시
- 응답의 헤더를 통해 컨텐츠의 길이, 캐시의 유효시간, ETag를 전송
- 캐시의 유효 시간이 지나면 서버로부터 다시 읽어들임
- 이 때 서버의 응답과 캐시로 가지고 있던 컨텐츠의 ETag가 같다면 업데이트 하지 않음
HTTP 메소드
| 메소드 | 요청에 body가 있음 |
요청에 body가 없음 |
설명 | |
| CREATE | POST | O | O | 리소스 생성 |
| READ | GET | X | O | 리소스 조회 |
| UPDATE | PUT | O | O | 리소스 수정 |
| DELETE | DELETE | X | O | 리소스 삭제 |
API
- 해당 프로그램의 구현을 알지 않아도 프로그램이 제공하는 기능을 쓸 수 있도록 한 인터페이스
EX) Google 지도를 사용할 때 컴퓨터에서 Google의 DB에 직접 접근하지 않고 API를 한 번 거쳐서 접근
만약 API가 없다면?
- 프론트엔드와 백엔드를 분리하기 어려워짐
- 프론트엔드만 수정하면 되는데도 백엔드까지 같이 배포하여야 함 (반대의 경우도 마찬가지)
- 웹 이외의 앱 등 다른 프론트엔드를 추가할 경우 백엔드를 통합하기 어려워짐
- Third Party에 어플리케이션 기능을 제공해야 할 경우 소스 코드와 DB 접근 권한을 노출시켜야 함
API는 프론트엔드와 백엔드의 분업을 쉽게 해줌
REST
- REpresental State Transfer - 표현 상태 전송
REST 제약 조건
클라이언트 - 서버 (Client-Server)
- 클라이언트와 서버의 기능은 완벽히 분리되어야 함
무상태 (Stateless)
- 요청을 통해 클라이언트의 '상태'를 서버에 저장해선 안 됨
- 대신 캐시나 JWT (Json Web Token) 등을 이용해야 함
캐시 처리 가능 (Cacheable)
- 클라이언트는 응답을 캐싱할 수 있어야 함
== 클라이언트가 같은 자료를 중복 요청하는 것을 막아 서버의 부담을 줄여줄 수 있음
계층화 (Layered System)
- 서버와 클라이언트 사이에 캐시 서버나 로드 밸런서 등의 중간 서버를 둘 수 있음
- 클라이언트는 대상 서버에 직접 연결되었는지, 혹은 중간 서버에 연결되었는지 알 수 없음
Code on demand
- 서버는 클라이언트가 직접 실행시킬 수 있는 로직을 전송할 수 있음
== 서버에서 클라이언트로 로직을 전송하여 클라이언트의 자원으로 실행할 수 있음
인터페이스 일관성 (Uniform Interface)
- 각각의 요청은 URI 등으로 식별됨
- 서버가 가지고 있는 리소스는 클라이언트의 응답과 구별됨
- 클라이언트는 서버로부터 전송받아 가지고 있는 정보만으로 리소스를 변경하거나 삭제할 수 있음
- 각각의 요청은 처리 방법에 대한 충분한 정보를 담고 있음
EX) 'GET/board/1' 이라는 요청만으로 '게시판의 1번 게시글을 읽는다' 라는 의미 전달이 됨 - HATEOAS : 해당 리소스에 대해 할 수 있는 모든 동작에 대한 URI를 제공
EX) 로그인
로그인을 하면 할 수 있는 행동들 (EX 글쓰기, 회원정보 수정) 등의 동작을 어떻게 해야하는지에 대해 URI를 제공
REST API
- 슬래시 (/)로 계층 관계를 나타냄
- URI를 이루는 리소스명은 동사보다는 명사로 사용해야 함
➡ HTTP는 상태나 행위를 가지거나 표현하지 않으므로 - 언더바(_), 대문자, 파일 확장자는 URI에 포함시키지 않아야 함
➡ 최대한 간결하게 만들고 혼동을 피하기 위해 - 리소스에 대한 행위는 HTTP 메소드를 이용 (GET / POST / PUT / DELETE)