네트워크의 시작
회선 교환의 방식
- 발신자와 수신자에 각각 할당된 전용선으로 연결
- 내가 연결하고자 하는 상대가 다른 상대와 연결중이 경우 해당 연결이 끊어져야 연결 가능
- 즉시성이 떨어짐
패킷교환 방식
- 소포를 보내듯 출발지와 목적지 정보를 가진 단위로 데이터를 잘게 나누어 전송함
IP(인터넷 프로토콜)/ IP Packet
- IP는 지정한 IP주소에 패킷이라는 통신단위로 데이터를 전달함
- 클라이언트와 서버 양방향에서 IP 패킷을 이용해 데이터 송수신 응답을 전달함
IP 패킷
출발지 IP, 목적지 IP 와 같은 정보 포함
IP 한계
비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송함
비신뢰성
- 중간에 패킷이 사라질 수 있음
- 패킷의 순서를 보장할 수 없음
TCP/UDP
TCP/IP 패킷
TCP 특징 (Transmission Control Protocol)
- 연결 지향 - TCP 3 way handshake (가상연결)
- 일단 연결은 해놓고 보내주는 방식
- SYN(Synchronize), ACK(Acknowledgement) - 데이터 전달 보증
- 순서 보장
- 신뢰할 수 있는 프로토콜 (UDP에 비해)
UDP 특징 (User Datagram Protocol)
- 하얀 도화지에 비유 (기능이 거의 없음)
- 비 연결 지향 - TCP 3 way handshake (X)
- 데이터 전달 보증 X
- 순서 보장 X
- 데이터 전달/순서가 보장되지는 않지만 단순하고 빠름
- 신뢰성보다는 연속성이 중요한 서비스(실시간 스트리밍)에 자주 사용
네트워크 계층 모델
OSI 7계층 모델 - 이론
각 계층은 독립적으로, 데이터 전달 시 다른 계층의 영향을 받지 않음
- 1계층 - 물리 계층- 디지털 또는 아날로그로 신호 변경
- 2계층 - 데이터링크 계층 - 브리지 및 스위치, MAC 주소
- 3계층 - 네트워크 계층 - 네트워크 간 라우팅 담당 - IP패킷 전송
- 4계층 - 전송 계층 - TCP/UDP 연결
- 5계층 - 세션 계층
- 6계층 - 표현 계층 - 문자코드, 압축, 암호화 등 데이터 변환
- 7계층 - 응용 계층 - 이메일 및 파일전송, 웹사이트 조회
데이터 캡슐화/역캡슐화
데이터 송신자 : 응용계층 ====> 물리계층
데이터를 상대방에게 보낼 때 각 계층을 거치면서 데이터에 필요한 정보들이 추가되는 데 이 정보를 헤더라고 함
헤더를 붙여 나가는 것을 캡슐화라고 함
데이터 수신자 : 물리계층 ====> 응용계층
데이터를 받는 쪽의 경우 데이터가 상위계층으로 전달되면서 각 계층에서 헤더가 제거됨. 이를 역캡슐화 라고 함.
응용계층에 도착하면 드디어 전달하려고 했던 원본데이터만 남게 됨
TCP/IP 4계층 모델 - 실무
4계층 - 어플리케이션 계층 - OSI 세션/표현/응용 계층
3계층 - 전송 계층 - OSI 전송 계층
2계층 - 인터넷 계층 - OSI 네트워크 계층
1계층 - 네트워크 인터페이스 계층 - OSI 물리/데이터링크 계층
응용 계층
클라이언트: 서비스를 요청하는 측
서버: 서비스를 제공하는 측
=> 클라이언트와 서버 모두 응용 계층에서 동작함
HTTP
HTTP 역사
HTTP/1.1
현재 주로 사용, 가장 중요한 버전, TCP 기반
HTTP/2
TCP 기반, 성능 개선
HTTP/3
UDP 기반 프로토콜
HTTP 특징
1. 클라이언트 서버 구조
- Response(응답) & Request(요청) 구조
2. 무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존하지 않음
- 장점: 서버 확장성이 높음 (응답 서버를 쉽게 바꿀 수 있음 => 무한한 서버 증설 가능)- 단점: 로그인이 필요한 서비스의 경우 유저의 상태를 유지해야하기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태 유지해야 함
- HTTP 메세지
- 단순함, 확장 가능
3. 비연결성(Connectionless)
TCP/IP의 경우 기본적으로 연결을 유지.
이 경우 클라이언트는 요청을 보내지 않더라도 연결을 계속 유지해야함 => 서버 자원이 계속 소모됨
HTTP는 비연결성을 가지므로 실제 요청을 주고받을때만 연결을 유지함 => 최소한의 자원으로 서버유지 가능케 함
트래픽이 많지 않고 빠른 응답 제공할 수 있는 경우 비연결성 GOOD.
=> 트래픽 많고 큰 규모의 서비스 경우 비연결성은 한계가 드러남
- 비연결성의 한계
- TCP/IP 연결 새로 맺어야함 : 3 way handshake 시간 추가- 웹브라우저로 사이트 요청 시 HTML + js, css, 추가이미지 등 수많은 자원이 함께 다운로드 됨
- 지금은 HTTP 지속연결(Persistent Connection)로 문제 해결
- HTTP/2, HTTP/3에서 더 많은 최적화
HTTP 헤더
HTTP 메세지 = 헤더 + 바디(페이로드: 메세지 본문)
헤더 형식
<field-name> : <field-value>Content-로 시작하는 것이 표현헤더Accept-로 시작하는 것이 컨텐츠협상헤더
요청(request)에 사용되는 헤더
From : 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소
- 현재 요청된 페이지 이전 웹페이지 주소
Referer을 통해 유입경로 수집 가능- 요청에서 사용
User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보 (웹브라우저 정보 등)
- 어떤 브라우저에서 장애 발생하는지 파악 가능
- 요청에서 사용
Host: 요청한 호스트 정보(도메인)
- 요청에서 사용
- 필수 헤더
- 하나의 서버가 여러 도메인을 처리할 때 호스트 정보 명시위해 사용
Origin: 서버로 POST요청을 보낼 때 요청을 시작한 주소 나타냄
Authorization: 인증 토큰(ex. JWT)을 서버로 보낼 때 사용하는 헤더
- "토큰의 종류(ex. Basic) + 실제 토큰 문자"를 전송
응답(response)에 사용되는 헤더
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- Server: Apache/2.2.22 (Debian), Server: nginx
Date : 메세지가 발생한 날짜와 시간
- Date: Tue, 15 Nov 1994 08:12:31 GMT
Location: 페이지 리디렉션
Allow: 허용 가능한 HTTP메서드
- 405에서 응답에 포함
- Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청하기까지 기다려야하는 시간
- Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
- Retry-After: 120(초 단위 표기)
콘텐츠 협상
콘텐스 협상에 사용되는 헤더
- Accept : 클라이언트 선호 미디어 타입 전달
- Accept-Charset : 클라이언트 선호 문자 인코딩
- Accept-Encoding : 클라이언트 선호 압축 인코딩
- Accept-Language : 클라이언트 선호 자연 언어
웹 캐시
캐시: 데이터나 값을 미리 복사해놓는 임시 장소
- 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용
- 캐시에 데이터를 미리 복사해놓으면 계산이나 접근시간 없이 빠른 속도로 데이터에 접근 가능
Cache-Control: max-age=60// 응답 수신 시 브라우저 캐시에 해당 응답 결과를 60초간 저장한다는 뜻- 캐시 유효기간 초과시, 다시 서버에 요청하고 60초간 유효한 데이터 응답을 또 받음 => 네트워크 다운로드 발생 => 기존 캐시 지워지고 새 캐시로 데이터 업데이트 => 캐시 유효시간 초기화
검증 헤더와 조건부 요청
Last-Modified를 통해 데이터가 마지막으로 수정된 시간정보를 헤더에 포함시킴
캐시 유효시간 초과 시 If-Modified-Since 헤더를 이용해 조건부 요청 가능
- 데이터 수정여부 점검 후 수정 안되었을 경우 응답 메세지에 이를 담아 알려줌
- HTTP Body는 응답 데이터에 없으며 상태 코드는 304 Not Modified (변경된 것이 없음)
- 클라이언트에서는 해당 응답 받은 후 캐시 갱신해주고 다시 일정시간 유효하게 해줌
ETag , If-None-Match
Last-Modified와 If-Modified-Since 보다 간단한 방식
Cache-Control 캐시 지시어
Cache-Control: max-age: 캐시 유효시간. 초단위Cache-Control: no-cache: 데이터는 항상 Origin 서버에 검증 하고 사용Cache-Control : no-store: 민감한 정보일 수 있으므로 저장하면 안됨. 메모리에서 사용 후 최대한 빨리 삭제
Expires 캐시 만료일 지정
- 캐시 만료일을 정확한 날짜로 지정
- HTTP 1.0부터 사용
- 더 유연한
Cache-Control: max-age사용 권장
프록시 캐시
프록시 : 클라이언트와 서버 사이에 대리로 통신 수행하는 것
프록시 서버: 프록시 중계 기능을 하는 서버
장점
클라이언트 혹은 서버가 다른 네트워크에 간접적으로 접속 가능하므로 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가짐
ex) 한국에 있는 클라이언트, 미국에 있는 원(origin)서버
프록시 캐시 관련 헤더
Cache-Control: public: 응답이 public 캐시에 저장되어도 됨Cache-Control: private: 응답이 해당 사용자만을 위한 것. private 캐시에 저장해야 함 (캐시 기본값)Cache-Control: s-maxage: 프록시 캐시에만 적용되는 max-ageAge: 60(HTTP 헤더) : 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
캐시 무효화
Cache-Control: no-cache: 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용할 것Cache-Control: no-store: 민감정보 있으므로 저장하지 말것 (메모리에서 사용 후 빨리 삭제)Cache-Control: must-revalidate: 캐시 만료 후 최초 조회 시 원서버에 검증해야함. 원서버 접근 실패 시 오류 발생(504-Gateway Timeout)Pragma: no-cache: HTTP 1.0 하위 호환, 옛날버전에서 쓰이던 거
