01. 인터넷 통신
지정한 IP주소에 패킷이라는 통신 단위로 데이터를 주고받는것
패킷: 출발지IP, 목적지IP, .. 등등이 포함
전달과정:
IP패킷을 만든다 > 패킷안의 출발지, 목적지 IP등을 인터넷으로 전달 >
노드 끼리 주소를 확인하여 목적지까지 정확하게 도달한다 > 목적지에서 메시지를 받았을 경우
OK메시지를 이미 온 노드를 기억하여 빠르게 답한다
없는 서버나, 서버를 잘못 기입했다: 비연결성
중간에 패킷이 사라지거나, 순서가 보장되지 않는다: 비신뢰성
을 해결하기위해 TCP/IP 통신을 요즘 보통함
데이터가 전송될때 IP패킷 안에 TCP 데이터, 그안에 메세지 데이터를 포함하여 전송한다
TCP(Transmission control protocol: 전송 제어 프로토콜)의 특징
-연결지향 3way handshake(가상 연결)
양쪽에서 syn, ack를 사용하여 연결확인을 한후 데이터 전송
-데이터 전달 보증
-순서보장
도착한 데이터의 순서가 다를시 전부 버리고 다시 요청하여 데이터를 받는다.
tcp안에 정보가 있음(순서정보, 검증정보 등등..) : 신뢰할수있는 프로토콜!
IP정보만으로는 어디서 필요한 패킷인지 알수없기때문에 PORT를 사용
서버안에서 돌아가는 애플리케이션을 구분할 때 사용
IP주소는 길고 외우기 어렵고 변경될수 있기때문에, DNS(도메인 네임시스템) 사용
이름은 그대로지만 IP정보는 변경될수 있음 (nslookup으로 도메인확인가능)
2. URI(=URL)
URL(locator), URN(name) 또는 둘다 추가로 분류될수있다.
URL: 리소스가 있는 위치 지정 URN:리소스에 이름을 부여
이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지는 않아서 잘안씀
URL 전체 문법
패스: 리소스 경로, 계층적 구조를 나타냄(명사로 이루어짐)
쿼리: 필요한 추가정보를 URL에 같이 실어보냄
웹브라우저 요청흐름(ex. www.naver.com를 검색하면 무슨일이 일어날까)
1) 웹브라우저가 HTTP 요청 메시지 생성
2) 소켓 라이브러리를 통해 OS TCP/IP에 전달
-TCP/IP연결(IP, PORT) > 전달 객체와 handshake 하여 연결 확보
-데이터 전달
3) TCP/IP 패킷 생성, HTTP 메세지 포함
4) HTTP 응답 메시지 받음
5) 내용이 데이터로 렌더링
4. HTTP의 특징과 메시지의 구조
1) 무상태: 클라이언트의 상태를 보존하지 않기때문에 무한 서버 증설(scale out)이 가능하고,
응답 서버를 쉽게 바꿀 수 있다.
때문에 추가데이터를 주지않으면 서버는 모른다. > 브라우저의 쿠키와 서버의 세션조합으로 상태 유지는 최소한만 사용
(request header 쿠키에 사용자를 식별할 수 있는 id)
:; 문제점은 서버에서 많은 세션의 정보를 저장하고 있어야하기 때문에 속도 이슈가 발생할 수 있다.
세션을 저장하는 서버를 두거나, 토큰 기반 서버를 구축하는 것도 방법이다.
2) 비연결성
HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
최소한의 자원을 유지하고 요청할 때만 연결하고,
지속연결을 통해 html, js, css, img 등의 수많은 자원을 다 받을때까지 열어둔다
- 메시지 구조
5. HTTP API
자원과 행위를 분리
=> HTTP의 이 기본 고민이 REST API에 녹아들어있음. 거의 같은 개념이라고 보여짐
REST(REpresentational State Transfer) :
Resouce oriended architeture 설계의 중심에 자원이 있고, HTTP Method(6가지)를 통해 자원을 처리하도록 설계하는것
1) 리소스와 행위를 명시적이고 직관적으로 분리한다.
- URI로 표현되는 리소스는 명사로 표현되어야한다
- 행위는 HTTP Method로 GET, POST, PUT(전체수정), PATCH(일부수정), DELETE를 분명한 목적으로 사용한다
2) Message는 Header와 Body를 명확하게 분리해서 사용한다
- entity에 대한 내용은 body에 담는다.
- 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header에 담는다.
- header와 body는 http header, http body로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있다.
3) API 버전을 관리한다. ? 이거 어렵다
- 환경은 항상 변하기 때문에 API의 signature가 변경될 수도 있음에 유의하자
- 특정 API를 변경할 때는 반드시 하위호환성을 보장해야한다
4) 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다
json형식이든 form-data 형식이든 하나로 통일한다. (=플랫폼 중립적)
6. HTTP 상태코드 소개
- 1xx: 요청이 수신되어 처리중(거의 사용되지 않음)
- 2xx: 요청 정상 처리(대표적인게 200)
- 3xx: 요청을 완료하려면 추가 행동이 필요
- 4xx: 클라이언트 오류, 잘못된 문법 등으로 서버가 요청 수행할 수 없음
401: 인증 필요 / 404: 요청 리소스를 찾을 수 없음
- 5xx: 서버 오류, 정상 요청 처리못함
??
그렇다면 RESTful 하지 않은 것은 어떤 방식임?
