application
socket
TCP/UDP
IP
Ethernet(MAC)인터넷 통신
- IP : 출발지 IP 주소와 목적지 IP 주소로 패킷 전달
- 원거리 통신 지원을 위한 통신 방법
- TCP : 출발지 Port, 목적지 Port, 전송, 순서, 검증 정보(checksum)
- 연결지향형 프로토콜, 순서 보장, 데이터 전달 보장
- 3 way handshake : SYN -> SYN+ACK -> ACK -> 데이터전송
- UDP : 순서가 빠름
- IP : 기기 찾기
- Port : 같은 IP 내 프로세스 찾기
- DNS : IP 주소 전화번호 부
- IP는 잊어버리기 쉽고 변경되기 쉬움
URI
- URI(Uniform Resource Identifier) : 식별(가장 큰 범위)
- URL(Locator) : 위치
- URN(Name) : 이름
- 위치는 변할 수 있지만, 이름은 변하지 않는다
- scheme:// (스키마)
: http(80), https(443) ,ftp 등 프로토콜 사용, 생략가능 - unserinfo@
: 거의 사용X - host
: 도메인명 또는 IP 주소를 직접 사용 가능, 호스트 명, www.google.com - :port
: 일반적으로 생략, http(80), https(443) - /path
: 리소스 경로, 계층적 구조, /home/file.jpg - ?quary
: key=value 형태, ?로 시작, &로 추가 입력 가능, ?keyA=valueA&keyB=valueB - #fragment
: html 내부 북마크, 서버에 전송하는 정보는 아님 - URL로 부터 HTTP 메시지를 뽑아냄 -> 패킷 전송(Port/IP 주소+HTTP 메시지) -> HTTP 응답 메시지
HTTP
- HTTP : 음성, 이미지, 영상, JSON, XML 등 대부분의 메시지를 전송
- HTTP 특징
- 클라이언트 서버 구조
- stateless, 비연결성
- HTTP 메시지
- 단순함, 확장가능
[클라이언트 서버 구조] : Request Response 구조
- 클라이언트는 요청, 서버는 응답
- 독립적으로 설계 가능
[무상태 프로토콜(stateless)] : 응답 서버를 쉽게 바꿀 수 있음
- 로그인과 같이 서버 상태 유지가 필요한 경우 쿠키나 세션 등을 사용하여 상태 유지
- 단점 : 전송된 데이터 양이 상대적으로 많음
[비연결성]
- 빠른 속도, 자원의 가용성 증가, HTTP 지속 연결
- HTTP 지속 연결(Persistent Connection) : 연결 -> HTML, JS, jpg 등 데이터 전달 -> 종료
- 이전 : 연결 -> HTML -> 종료, 연결 -> JS -> 종료, 연결 -> jpg -> 종료
HTTP 메시지
[HTTP 요청 메시지]
- 시작라인 : HTTP 메서드(GET, POST, PUT, DELETE), 요청대상, HTTP 버전
[HTTP 응답 메시지]
- 시작라인 : HTTP 버전, HTTP 상태 코드
- HTTP 해더 : HTTP 전송에 필요한 부가정도
- HTTP 메시지 바디 : 실제 전송할 데이터
=> 단순 & 확장용이
HTTP API URI 제작
- URI는 리소스만 식별!
- 리소스와 해당 리소스를 대상으로 하는 행위는 분리할 것
- 행위 => HTTP 메서드
-
GET: 리소스 조회- 데이터를 쿼리를 통해 전달
-
POST: 등록(주로), 데이터 변경, 프로세스 처리(요청 데이터 처리)- 애매하면 POST, 대부분의 기능을 담당
-
PUT: 완전히 대체, 생성- 리소스가 있으면 완전히 대체, 리소스가 없으면 생성
- POST와 차이점 : 클라이언트가 리소스 위치를 알고 URI를 지정
- 부분 변경 불가 ~> PATCH
-
PATCH: 수정(부분변경) -
DELETE: 삭제 -
HEAD,OPTIONS,CONNECT,TRACE등
[HTTP 메서드의 속성]
- 안전(Safe) : 리소스 변경 X
- GET, HEAD
- 멱등(Idempotent) : 몇 번 호출하든 결과가 동일 ~> 활용 : 자동 복구 메커니즘
- GET, PUT(결과를 대체하므로 여러번 해도 결과는 같음), DELETE(결과를 삭제하므로 여러번 해도 결과는 같음)
- POST(멱등X -> 두 번 호출하면 같은 결제가 중복해서 발생할 수 있음)
- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않음 -> 변경되면 멱등하지 않음
- 캐시가능(Cacheable) : 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD 정도만 캐시로 사용
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음
Server Engineer