TCP 3-way handshake(Connection)
- 연결 성립
1. 클라에서 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다.
2. 서버는 클라의 요청인 SYN(a) 를 받고 요청 수락의 ACK(a+1)과 SYN(b) 가 설정된 패킷을 발송한다.
3. 클라는 서버의 수락 응답 패킷를 받고 서버로 SYN(b+1) 을 보내면 연결이 성립된다.
TCP 4-way handshake(Connection close)
- 연결 해제
- 클라에서 종료의 의미인 FIN 플래그를 발송한다.
1. 서버에서 클라 요청인 FIN을 받고 확인 메세지로 ACK를 보낸다. 그 후 데이터를 모두 보낼 때 까지 TIME-OUT 된다.
2. 데이터를 모두 보내고 통신이 끝나면 연결 종료의 의미로 클라에 FIN 플래그를 발송한다.
3. 클라는 FIN을 받으면 확인의 의미로 ACK를 보낸다.
4. 클라의 ACK 메세지를 받은 서버는 소켓 연결을 close 한다.
5. 클라는 아직 못받은 데이터가 있을 경우를 대비하여 일정 시간 동안 세샨을 남겨놓고 잉여 패킷을 기다리는 과정을 거친다(TIME-WAIT)
SYN과 ACK 는 뭘까
- SYN : Synchronize Sequence Number 의 약자
연결 과정과 연결 해제 과정이 차이가 나는 이유
- 클라에서 전송을 마쳤다고 해도 서버측에서는 아직 전송을 못했을 경우가 남아 있을 수도 있어서 FIN에 대한 확인 메세지민 보내고
데이터를 모두 전송한 후에 자신도 FN 메세지를 보내기 때문
서버에서 FN 전송 전에 패킷이 유실되어 FN보다 늦게 도착한 경우
- 이런 상황에 대비하여 클라에서 서버로부터 FN을 받더라도 일정시간 세션을 남겨놓고 패킷을 기다린다. -> TIME WAIT
HTTP와 HTTPS 차이
-
주로 80번 포트를 사용하고, 비연결, 무상태 프로토콜이다.
-
주로 443번 포트 사용, HTTP의 보안이 강화된 프로토콜, 통신을 텍스트로 하지만 정보를 암호화하는 SSL, TLS 를 이용하여 데이터 암호화함 데이터의 적절한 보호를 보장한다.
HTTPS 사용하는 이유
- 브라우저가 서버에 어떤 정보를 요청하면 서버는 요구하는 정보를 제공한다.
- 이때 주고 받는 정보가 민감한 정보일 경우 네트워크 상에서 제3자가 정보를 가로채면 보안상 문제가 발생하기 때문에 중간에서 정보를 볼 수 없도록 정보를 암호화 하는 방식은 HTTPS 를 사용하는 것
HTTPS 원리
- 공개키 알고리즘 방식
- 암호화, 복호화할 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법
- 공개키 : 모두에게 공개, 공개키 저장소에 등록
- 개인키 : 개인에게만 공개, 클라-서버 구조에서는 서버에서 가지고 있음
- 클라 -> 서버
- 사용자의 데이터를 공개키로 암호화한다. (공개키를 얻은 인증된 사용자)
- 서버로 전송 (데이터를 여기서 가로채가도 개인키가 없다면 복호화할 수 없다)
- 서버의 개인키를 통해 복호화하여 요청 처리함
HTTPS 장단점
- 장점 : 네트워크 상에서 열람 및 수정이 불가능하다.
- 단점 : 웹 서버 부하, 느림, 인증서 유지하는데 비용이 들어간다,
CORS
- Cross Origin Resource Sharing
- 어떤 장소에서 실행 중인 웹 앱이 다른 장소의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 것
- 보안 상의 이유로 브라우저에서 CORS 요청을 제한을 합니다. 즉 API를 사용하는 웹 앱은 자신과 같은 곳에 있는 리소스만 불러올 수 있습니다.
- 해결방안
- 서버 : HTTP 응답헤더에 CORS를 허용해주는 옵션을 추가한다.
- 클라 : 브라우저와 서버 사이에서 프록시를 해주는 서버를 추가한다.
TCP와 UDP
- UDP : User Datagram Protocol , 비연결형 프로토콜이고 UDP는 손상된 세그먼트의 수신에 대한 재전송을 하지 않습니다. 송신하는 측에서 일방적으로 보내는 특성이 있고 실시간 서비스에 이용된다.
- TCP : Transmission Control Protocol, 송신자와 수신자 모두 소켓이라는 종단점을 생성하여 이루어진다. 신뢰성과 순차적 전달을 위헤 탄생함
모든 연결은 전이중, 점대점 방식이고 전이중은 전송이 양방향으로 일어날 수 있고, 점대점은 양 끝에 종단점이 있다는 것이다.
DNS Round Robin
- 여러 대의 서버 중에서 랜덤하게 하나를 선택하여 사용자에게 알려주는 것이다.
- 결과로 웹 사이트에 접속하는 다수의 사용자가 실제로는 복수의 웹 서버에 접속하게 되어 부하를 분산하는 방식
- 라운드 로빈은 기본적으로 헬스 체크 기능을 제공하지 않기 때문에 에러가 난 경우 어디서 에러가 났는지 알 수 없다.
- 해결 방안 : 헬스 체크기능이 붙어 있는 DNS를 이용하면 된다.
웹 통신의 흐름
-
주소창에 특정 url을 입력했을 떄
- 브라우저
1. 브라우저 내부의 규칙에 따라 의미 조사
2. 의미에 따라 HTTP REQ 메시지를 만든다.
3. 메세지를 서버로 전송한다. (브라우저에는 메세지 송출 기능이 없어서 OS에서 담당한다.
- LAN
1. 프로토콜 스택이 브라우저에서 메세지 받음
2. 메시지를 패킷에 저장
3. 수신처 주소 등의 제어정보를 추가함
4. 그 다음 패킷을 LAN 어댑터에 넘긴다.
5. LAN은 패킷을 전기신호로 변환한다.
6. 신호 송출
- 허브
1. LAN에서 발생된 패킷은 허브를 경유하여 인터넷 접속용 라우터에 도착함
2. 라우터는 패킷을 통신사에 전달함
3. 인터넷으로 발송된다.
- 엑세스 회선
1. 발송된 패킷이 엑세스 회선에 의해 통신사 라우터에 발송된다.
2. 통신사 라우터를 거쳐서 인터넷 핵심부로 들어가게 된다.
3. 고속 라우터에서 패킷이 목적지로 향하게 된다.
- 방화벽
1. 패킷이 웹 서버의 LAN에 도착한다.
2. 방화벽이 패킷을 검사한다.
3. 패킷이 웹 서버까지 가야하는지 검사하는 캐시서버가 존재한다.
4. 굳이 서버까지 안가도 되는 경우를 찾아내어 캐시서버에 찾는 데이터가 있다면 웹 서버까지 안가고 캐시서버에서 해당 값을 읽을 수 있다.
- 웹 서버
1. 패킷이 웹 서버에 도착하면 해당 서버의 프로토콜 스택이 패킷을 추출하여 메세지 복원하고 앱에 넘긴다.
2. 받은 웹앱서버는 요청에 따라 응답 메세지를 넣어 응답한다.
3. 왔던 방식 그대로 응답 메세지가 클라에 전달된다.
웹 통신의 흐름
- 링크를 치면 해당 브라우저 내부 규칙에 따라 의미를 조사하고, 그 의미에 따라 http 메세지를 만든 다음에 메세지를 서버로 전송합니다. 이때 브라우저에는 송출 기능이 없어서
운영체제에서 송출 기능을 담당하게 됩니다. 그 다음에 프로토콜 스택에서 메세지를 받아서 메시지를 수신처 주소 등을 포함하여 패킷에 저장한 다음에 LAN 어댑터에 넘기면
LAN 에서 전기신호로 변환된 후 라우터를 거쳐서 통신사 인터넷으로 발송되어서 액세스 회선에 의해 인터넷 핵심부로 들어가고 그 후에 목적지로 향하게 됩니다.
그 후에 패킷이 서버의 LAN에 도착하게 되면 방화벽이 해당 패킷을 검사하고 문제가 없다면 패킷이 웹 서버까지 도달해야 하는지를 검사하는 캐시 서버에서 검사를 한 후에
갈 필요가 없다면 캐시 서버에서 응답하고, 가야한다면 웹 서버 내부로 접근합니다. 패킷이 웹 서버 내부에 도착하면 서버의 프로토콜 스택이 패킷을 추출해서 메세지를 복원합니다.
해석이 끝난 메세지를 보고 그 요청에 따라 응답 메세지를 왔던 방식 그대로 응답합니다.
OSI 7계층
컴퓨터 네트워크 프로토콜은 디자인과 통신을 계층으로 나누어 설명한 것, 각 계층은 하위 계층의 기능만을 이용하고 상위 계층에 기능을 제공한다.
1. 물리 계층 : 하드웨어 전송 기술, 전송단위 Bit
2. 데이터 링크 : 점대점 간 신뢰성 있는 전송을 보장하기 위한 계층, 오류 제어 및 흐름 제어가 필요함. 주소값 물리적 할당(MAC) 전송 단위 FRAME, ex: 이더넷
3. 네트워크 : 여러개의 노드를 거칠 때 마다 경로를.찾아주는 역할, 라우팅, 흐름 제어, 세그멘테이션, 오류 제어, 인터네트워킹 등을 수행함, 전송 단위 DATAGRAM(packet)
4. 전송 계층 : 양 끝단 사용자들이 신뢰성 있는 데이터를 주고 받을 수 있도록 한다. 특정 연결의 유효성을 검증한다. Stateful, 연결 기반이다. 단위는 세그멘트
5. 세션 계층 : 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공함, 양방향, 반이중, 전이중 통신등을 수행함, TCP/IP 세션에 대해 책임을 짐
6. 표현 계층 : 코드간의 번역 담당 MIME 인코딩, 암호화 등의 동작이 이루어짐
7. 응용 계층 : 응용 프로세스와 직접 관계하여 일반적인 서비스 수행
쿠키와 세션의 필요성
- HTTP 프로토콜의 경우 의존 관계가 없음
- 현재 접속한 사용자가 이전에 접속한 사람과 같은 사람인지 아닌지 구별할 수 없음
- 이전 요청과 현재 요청이 같은 사람인지 판별하기 위해 상태를 유지할 필요가 있음
쿠키
- 로컬에 저장되는 키와 값이 들어있는 파일
- 이름, 값, 유효 시간 등을 포함함
- 클라이언트 상태 정보를 저장
- 구성 요소
- 이름
- 값
- 만료시간
- 도메인
- 경로
- 보안 연결
- httponly
- 동작 방식
- 브라우저에서 서버에 요청
- 상태를 유지하고 싶은 값을 쿠키로 생성함
- HTTP 헤더(Set-Cookie) 에 담아서 전송
- 전달받은 쿠키는 브라우저에서 관리하고 있다가 다음 요청시 헤더에 담아 전송
- 서버에서는 쿠키 정보를 읽어 이전 상태 정보 확인 후 응답
세션
- 일정 시간 동안 같은 브라우저로부터 오는 요청을 상태로 보고 상태를 유지하는 것
- 서버에 접속한 이후부터 종료시까지 계속 유지함
- 동작 방식
- req
- 서버에서 해당 브라우저에 sessionID 적용
- 응답시 Set-cookie 쿠키에 sessionID 포함하여 전송함
- 브라우저는 브라우저를 닫을 때 까지 다음 요청에 sessionID 쿠키를 헤더에 넣어서 전송함
쿠키와 세션의 차이점
- 저장 위치
- 쿠키 : 로컬
- 세션 : 서버
- 보안
- 쿠키 : 클라에 저장되므로 보안에 취약
- 세션 : 쿠키를 이용해서 sessionID 만 저장하고 서버에서 처리 비교적 좋음
- 생명 주기
- 쿠키 : 만료시간 존재
- 세션 : 브라우저 닫으면 없어짐
- 속도
- 쿠키 : 클라에 저장되어 서버에 요청시 빠름
- 세션 : 저장된 정보가 서버에 있어 서버가 처리해야하는 요소가 필요하여 비교적 느림