1. 웹서버

1.1 웹이란?

인터넷

인터넷은 여러 통신망을 하나로 연결한다는 의미를 가짐(TCP/IP로 통신).

웹

인터넷 연결된 사용자 간의 정보 공유 시스템(이미지와 문자를 HTTP로 전송하는 정보시스템)

HTTP

단순한 텍스트를 넘어서 하이퍼링크를 통해서 웹 상에 존재하는 여러 문서나 리소스에 접근을 할 수 있다.

• 상태 정보를 저장하지 않는 Stateless
  ( 각 요청은 서로 독립적이며, 이전 요청의 상태/정보는 기억 x => 쿠키,세션,토큰이 필요 )

• 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless
  ( HTTP/1.0은 해당이 되지만, HTTP/1.1은 해당이 되지 않음. )

• 장점
  연결 상태 처리, 상태 정보를 관리할 필요 x -> 간단한 디자인, 독립적 응답

• 단점
  매번 인증해야함.

1.2 Cookie vs. Session vs. Token

1. Cookie 인증

{ key : value }

• 보안에 매우 취약 (XSS, 자바스크립트 해킹)

• 용량 제한

• 브라우저간 공유가 불가능

2. Session 인증

민감한 인증 정보를 브라우저가 아닌 서버 측에 저장/관리
( 핵심 정보는 클라이언트가 아닌 서버에서 모두 관리 )
{
{ key1 :
creationTime : value1,
lastAccessedTime : value2,
userId : value3
}
,
{ key2 :
creationTime : value4,
lastAccessedTime : value5,
userId : value6
}
}

1. 유저가 웹사이트에서 로그인 -> 세션이 서버 메모리(DB)상에 저장

2. 서버에서 브라우저에 쿠키에다가 Session Id 저장

3. 브라우저는 해당 사이트에 대한 모든 요청에 Session Id를 쿠키에 담아 전송.

4. 서버는 클라이언트가 보내는 Session Id와 서버의 Session id를 비교하여 인증.

• 단점

• 세션 ID 자체를 탈취당하면 보안상 문제( IP 특정을 통해 해결 가능. )

• 서버에서 세션 저장소를 사용( Stateful ) -> 요청이 많으면 부하가 심화

3. Token 인증

인증이 될 경우에만 토큰을 발급.(요청 헤더에 토큰을 심어서 전송)
토큰은 세션과 달리 클라이언트에 저장되기 때문에 용량문제가 적다.
또한 토큰 자체의 위변조 여부만 파악하면 된다.
( 앱에서는 쿠키, 세션이 없음, Stateless함 )

1. 사용자 아이디/비밀번호 로그인

2. 서버 측에서 사용자에게 유일한 토큰 발급

3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고,
   서버에 요청을 할 때마다 해당 토큰에서 요청 헤더에 포함시켜 전달

4.서버는 전달받은 토큰을 검증하고 요청에 응답

• 단점

• 토큰 자체의 데이터 길이가 길어 -> 인증 요청이 많아질수록 네트워크 부하가 심해짐.

• Payload 자체는 암호화가 되지 않음 -> 유저의 중요한 정보를 담을 수 없음

• 토큰 탈취시, 위험( 따라서 TTL 설정 )

세션 기반 vs. 토큰 기반

단일 도메인이라면 세션 기반 인증을 쓰고, 아니면 토큰 기반 인증이 더 적합함.
왜냐하면 도메인별 세션 관리 쿠키가 CORS때문에 관리가 어렵다.

3.1 JWT( JSON WEB TOKEN )

인증에 필요한 정보들을 암호화 시킨 JSON 토큰
Base64 Encoding으로 직렬화

구성은 다음과 같음
[ Header.Payload.Signature ]

• Header : JWT에서 사용할 타입 + 해시 알고리즘

• Payload : 서버에서 첨부한 사용자 권한 정보 및 데이터

• Signature : Header, Payload를 Base64로 Encoding을 한 후 Header에 명신된 해시함수를 적용하고, 개인키로 서명.

• 장점
  : 인증을 위한 별도의 저장소가 필요 없음, stateless

• 단점
  : 토큰의 길이가 늘어날수록 네트워크 부하, Base64 Encoding으로 탈취당하면 데이터 볼 수 있다.

Base64 Encoding

Binary Data -> Text로 바꿈.
(Binary Data를 6bit씩 자른 뒤 -> 6bit에 해당하는 문자를 Base64 색인표에서 찾아 치환)

그런데, 모든 binary bit가 6bit씩 끊어지는 것은 아니다.
010011 010110 000101 101110 01110 (01 -> 010000) => padding 0을 추가해서 6비트로 만든다.
T W F u e Q = =

: TWFueQ==

전송해야 될 데이터의 양이 약 33% 증가함. + CPU 연산 추가

binary를 ASCII로 쓸 경우 다음과 같은 문제 발생

• ASCII는 7bit Encoding인데 나머지 1bit를 처리하는 방식이 시스템 별로 다름.

• 바이너리 -> 텍스트로 전송 :ASCII로 안전하게 인코등 가능

• HTTP는 텍스트 기반이므로 문자열로 전송 가능

• 시스템 간 호환성 문제를 회피.

심화 HTTPS

HTTP + SSL/TLS 프로토콜을 추가한 통신 규약

• 데이터 전송의 보안을 강화하기 위해 암호화

• 비대칭 키를 이용함.

1. 개인 키
   웹 사이트 소유자가 보유

2. 공개 키
   여러 클라이언트들이 접근

설정안하면, 스니핑(데이터 가로챔, 도청)에 취약

1. 암호화 전:
완전히 읽을 수 있는 텍스트 문자열입니다

2. 암호화 후:
ITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo6AfSHlNtL8N7ITEwIXc1gU5X

TLS 핸드셰이크

SSL 인증서 보안 기술은 다음과 같다.

• 대칭키

• 비대칭키
  개인키 없이 절대로 복호화가 불가능.
  "공개키로 암호화 -> 개인키로 복호화."

• 인증(authentication)

• 디지털 서명과 이를 수행하는 인증기간(CA)

• 공개키를 안전하게 전달하는 프로토콜

• 위변조 확인하는 메시지 무결성 알고리즘.

(https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/)

(https://brunch.co.kr/@sangjinkang/38)

(2)에서 서버의 공개키가 담긴 SSL 인증서를 응답하는데,
이때 CA의 비밀키로 암호화된 상태임.

(3)대부분 브라우저는 CA가 있으므로, 내장 CA 공개키로 암호화된 인증서를 복호화를 한다.
(만약에 실패하면, 브라우저 경고 발생)

(4)SSL 인증서에서 딸려노 공개키로 암호화해서 서버로 전송.

(5)서버는 자기 비밀키로, 브라우저가 보낸 값을 복호화

(6)SSL handshake를 종료하고, HTTPS 통신 시작

2. 브라우저

(https://velog.io/@wlwl99/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EA%B5%AC%EC%A1%B0)

1. 사용자

브라우저에 URL 주소 입력
URL 파싱(프로토콜/도메인/포트)

참고 )
프로토콜, 호스트, 포트 이 3개가 같아야 동일 출처 정책(Same-Origin Policy)이다.

CORS

출처가 다른 도메인에서의 AJAX 요청이라도 서버 단에서 데이터 접근 권한을 허용.
(서버 단에서 특정 도메인을 허용해주면 된다.)

2. DNS 서버

사용자가 입력한 URL 중 도메인 네임을 검색하고,
도메인 네임에 일치하는 주소를 찾아, 사용자가 입력한 URL정보와 함께 전달.
(DNS응답으로 IP주소를 받는다.)

"브라우저"는 DNS로부터 응답받은 IP주소를 캐싱한다.
그리고 사용자가 URL 입력 시, 브라우저는 먼저 캐싱된 데이터 중에서
해당 도메인에 해당하는 IP 주소가 있는지 부터 확인.

만약에 캐시미스이면, DNS에 IP주소를 요청한다.

(https://velog.io/@gyumin_2/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%EC%8B%9C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%8E%B8)

• Local DNS(ISP가 제공)
  LAN 연결 시, 통신사가 공인 IP를 할당하는데, 각 통신사의 DNS서버가 등록되어 있다.

• Root DNS
  Local DNS가 IP를 조회할 때 가장 먼저 요청하는 DNS

과정

우리가 주소창에 domain.co.kr 을 입력했다고 가정할 때 아래의 과정을 통해 IP 주소가 조회됩니다.

1. 브라우저는 먼저 Local DNS에 domain.co.kr 에 해당하는 IP 주소를 요청합니다.

2. Local DNS에는 해당 도메인에 대한 정보가 있을 수도 있고 없을 수도 있습니다. 만약 Local DNS에 해당 도메인에 대한 IP 주소가 있다면 브라우저에게 응답하고, 없으면 Local DNS는 루트 DNS에게 해당 도메인의 IP를 요청합니다.

3. 루트 DNS는 해당 도메인 IP 정보를 갖고 있다면 Local DNS에 응답하고, 없다면 어떤 DNS에 요청해야 하는지를 알려줍니다. domain.co.kr 를 예로들면 루트 DNS는 .kr 도메인을 관리하는 DNS에 물어보라고 Local DNS에 응답합니다.

4. Local DNS는 .kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, .kr 도메인을 관리하는 DNS는 해당 IP 정보를 갖고 있다면 해당 IP 주소를 Local DNS에 응답하고, 없다면 .co.kr 도메인을 관리하는 DNS에 물어보라고 응답합니다.

5. Local DNS는 .co.kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, .co.kr 도메인을 관리하는 DNS는 해당 IP 정보를 갖고 있다면 해당 IP 주소를 Local DNS에 응답하고, 없다면 domain.co.kr 도메인을 관리하는 DNS에 물어보라고 응답합니다.

6. Local DNS는 domain.co.kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, domain.co.kr 도메인을 관리하는 DNS는 Local DNS에 해당 도메인의 IP 주소를 응답합니다.

7. 이를 수신한 Local DNS는 domain.co.kr 도메인에 대한 IP 주소를 캐싱하고, IP 주소를 브라우저에게 응답합니다.

이와 같이 Local DNS 서버가 루트 DNS를 시작으로 하위 도메인을 관리하는 DNS에게 요청하여 IP주소를 찾는 과정을 Recursive Query라고 부릅니다. 그리고 IP 주소를 찾는 과정이 이렇게 길고 복잡하기 때문에 브라우저는 IP 주소를 캐싱합니다.

. -> .kr -> .co.kr -> domain.co.kr (순서)

3. HTTP 프로토콜
   전달 받은 IP주소와 웹 페이지 URL 정보는 HTTP 프로토콜을 사용해 HTTP 요청 메시지를 생성

4. TCP/IP 프로토콜
   앞선 HTTP 메시지는 TCP 프로토콜에 의해서 인터넷을 거쳐 해당 IP 컴퓨터로 전송되고,
   도착한 HTTP 메시지는 HTTP 프로토콜을 이용해 웹 페이지 URL 정보로 변환

5. 웹 서버
   변환된 정보에 해당하는 데이터를 검색하여 찾아낸 뒤, HTTP 응답 메시지를 생성
   (TPC를 사용해 인터넷을 거쳐 사용자의 컴퓨터로 전송 및 도착한 HTTP 메시지는 웹 페이지 데이터로 변환)

6. 웹 브라우저
   변환된 데이터가 웹 브라우저에 출력됨.

웹 서버 vs WAS

(https://velog.io/@gyumin_2/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%EC%8B%9C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%8E%B8)

1. 정적 페이지( 웹서버 )
   클라이언트가 요청을 보내면 서버는 미리 저장된 웹 페이지를 반환한다.
   (정적 콘텐츠 반환)
   Apache, NGINX

2. 동적 페이지( WAS = 웹서버 + 웹컨테이너(JSP,Servlet 실행 가능한 소프트웨어) )
   클라이언트에게 요청을 받은 후 서버에 의해 추가적인 처리 과정을 거쳐 응답된 페이지를 의미
   (매번 다른 결과)
   또한, 웹 서버가 단독으로 처리하기 어려운 DB조회 및 다양한 비즈니스 로직을 처리해 동적 페이지를 제공
   Tomcat

웹 서버와 WAS 분리

WAS는 정적 콘텐츠 처리 못하는 것이 아니라! 정적인 콘텐츠 + 동적 콘텐츠 모두 처리한다.

WAS는 DB 조회나 프로그래밍 로직 처리도 같이 하므로 부하가 크다.

따라서, 트래픽이 많다면 WAS 앞에 웹 서버 1개 두어 정적인 요청은 웹 서버가 처리하도록 하는 것이 좋다.
(NGINX 웹 콘텐츠 캐싱)

2. TCP vs. UDP

2.1 TCP/IP

[ TCP 특정 ]

• 연결 지향 방식으로 "패킷" 교환 방식 사용

• 3-way handshaking으로 연결, 4-way handshaking을 통해 해제

• 흐름 제어 및 혼잡 제어

• 높은 신뢰성을 보장

• UDP보다 느림

• Full-Duplex, Point to Point 방식

4-way handshaking

1. step 1 : 클라이언트 - (FIN) -> 서버

• 클라이언트가 서버에게 연결 종료를 요청하는 FIN 세그먼트 전송

2. step 2 : 클라이언트 <- (ACK) - 서버

• 서버는 FIN을 받고, ACK을 클라이언트에게 보내고 자신의 통신이 끝날때까지 기다린다.

• 아직 남은 데이티가 있다면 마저 전송을 마친 후 close()

• 클라이언트는 ACK을 받은 후 서버가 남은 데이터 처리를 끝내고 FIN 패킷을 보낼 때까지 기다린다.(FIN_WAIT_2)

3. step 3 : 클라이언트 <- (FIN) - 서버

• 서버가 데이터를 모두 보냈다면 -> 연결 종료에 합의 한다는 의미로 FIN을 역으로 전송

• ACK을 받을 때까지 기다리는 LAST_ACK 상태

4. step 4 : 클라이언트 - (ACK) -> 서버

• 클라이언트는 FIN을 받고, 응답 ACK을 서버에게 전송.

• 서버는 TIME_WAIT을 통해서 대기

만약 서버가 ACK을 받으면, Closed -> TIME_WAIT이 끝나면 클라이언트도 Closed

연결 지향 vs. 비연결 지향

1. 연결 지향( TCP )

• 통신 연결을 유지

• 연결을 계속 유지 -> 비용이 비쌈.

• 이미 연결이 된 상태이므로, 상대방을 알 수 있음.
  ( 송수신자 간 먼저 연결이 설정된 후, 데이터 전송 )

• 서버와 클라이언트 1:1

• 스트림 전송으로 전송 데이터의 크기가 무제한

• 스프리밍 서비스에 불리.( 손실된 경우 재전송 요청 )

연속성보다 신뢰성 있는 전송이 중요할 떄 사용하는 프로토콜.

2. 비연결 지향( UDP )
   데이터를 데이터그램( 독립적인 관계를 지닌 패킷 ) 단위로 처리하는 프로토콜

• 통신 연결 유지 x

• 연결 유지 x -> 싸다.

• 매번 새롭게 연결이 성립 -> 매 연결 시 자신이 누구인지 알려줘야.

HTTP => stateless, connectionless( 비연결 )

TCP => 연결지향 프로토콜

• 연결 설정이나 해제의 필요 없이 한쪽에서 일방적으로 전송.

• 신뢰성이 낮다.
  ( TCP와 달리, 패킷에 순서를 부여하여 재조립을 하거나 흐름 제어, 혼잡 제어가 없다. )

신뢰성보다는 연속성이 중요한 서비스에 적용

• 연결 자체가 없다 -> 서버 소켓, 클라이언트 소켓 구분 X

• 소켓을 활용하되 IP,PORT 기반으로 데이터 전송

• 서버 : 클라이언트 = 1:N, N:M, 1:1 등 가능.

흐름제어 및 혼잡제어

• 흐름제어
  : 데이터 송수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우 방지.

• 혼잡제어
  네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지.

OSI 7계층

• 7 계층(응용 계층) : 사용자에게 통신을 위한 서비스 제공. 인터페이스 역할

• 6 계층(표현 계층) : 데이터의 형식(Format)을 정의하는 계층 (코드 간의 번역을 담당)

• 5 계층(세션 계층) : 컴퓨터끼리 통신을 하
  기 위해 세션을 만드는 계층

• 4 계층(전송 계층) : 최종 수신 프로세스로 데이터의 전송을 담당하는 계층 (단위 :Segment) (ex. TCP, UDP)

• 3 계층(네트워크 계층) : 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층 (단위 :Packet) (ex. Router)

• 2 계층(데이터링크 계층) : 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 계층 (단위 :frame) (ex. 이더넷)

• 1 계층(물리 계층) : 데이터를 전기 신호로 바꾸어주는 계층 (단위 :bit) (장비: 케이블,리피터,허브)

출처: https://dev-coco.tistory.com/161 [슬기로운 개발생활:티스토리]

HTTP Method

• GET : 데이터 조회
  URL에 데이터가 노출 -> 보안적으로 중요한 데이터 포함 X

• POST : 데이터 등록
  Body에 데이터를 포함. GET보다 안정.

• PUT : 데이터 변경

• PATCH : 일부 데이터만 변경

• DELETE : 데이터 삭제