OSI 7계층

application layer
presentation layer
session layer

transport layer
network layer
data link layer
physical layer

이는 tcp/ip 4계층으로 변환되기도 하는데,

• tcp/ip 5계층
  application layer
  transport layer
  internet layer
  network access layer
  로 application은 데이터를 만들어내고 보내는 것에 집중
  transport 계층은 tcp/UDP등의 프로토콜로 하위 계층으로 전송
  인터넷 계층은 ip프로토콜로 컴퓨터 노드로 전송
  network access 계층은 실제 랜선, 랜카드 드라이버와 같은 물리적/장비적 연결에 집중한다.

인터넷 통신의 과정

TCP/UDP

전송 계층은 프로토콜 2개이다.

• TCP

  • 연결형 프로토콜 (3 way handshake)
  • 데이터의 순서
  • 신뢰성 보장 - 데이터가 누락없이 전달됨을 프로토콜이 보장

• UDP

  • 비연결, 패킷의 신뢰성,순서도 보장 X
  • 속도가 빠르다
  • 약간의 누락을 감수해도 빠른 통신의 필요한 서비스에 적합
  • 의외로 무결성(checksum)은 tcp와 동일한 레벨로 보장.

URI

URI는 웹자원에 대한 식별자로, URL(location)보다 광범위한 개념이다.
우리가 접속하는 웹의 주소가 URI인데 크게는
scheme/host/port/path/query 로 나뉘어져 있다.
scheme: 사용하는 프로토콜 - http,https,ftp
host: 호스트명이나 도메인명, IP주소 - localhost,naver.com, 200.1.1.1 등
path: 리소스의 경로 - user/premium , image/dog/husky
query: 리소스에 대한 parameter로 ?로 시작해 여러개면 &로 연결

HTTP

hyper text transfer protocol. 텍스트,이미지,영상등의 자원을 전송하는 프로토콜이다.
http는 기본적으로 아래의 특징을 갖는다.

• 클라이언트 서버 구조
• 무상태 프로토콜
• 상태가 필요한 경우 db,세션,쿠키,jwt등을 통해 보완한다.
• 비연결성

http메시지 구조

• start-line : 요청/응답의 자원이나 상태가 작성
  ex) HTTP/1.1 200 OK , GET/search?q=hi&...

• header : http전송에 필요한 부가정보 기록/ 메세지 바디의 크기,요청타입 등
  임의의 헤더도 추가 가능
  ex) Content-Type: application/json , Authorization: BASIC xxxxxx

• CRLF: header와 body를 구분

• body: 전송할 데이터가 들어감: html,이미지,json등 다양한 타입

http상태 코드

요청에 대한 서버측으로부터의 상태를 보여줌

• 200대: 요청 정상 처리
  • 200(OK), 201(created), 202(accepted), 204(no content)
• 300대: 요청 완료를 위해 추가 행동이 필요/리다이렉션
  • 301(moved permanently) , 302(found)
• 400대: error
  • 400(bad request), 401(unauthorized), 404(not found)
• 500대: 서버 error
  • 500(internal server error)

SSL,TLS

암호화 기반 인터넷 보안 프로토콜로, HTTPS에서 사용한다.
SSL,TLS는 인증서가 있는 웹사이트만 실행할 수 있다.
이 인증서가 없다면 https를 사용할 수 없다.

jwt

세션은 서버측 메모리,db에 사용자 정보를 저장하기에 필연적으로 공간을 차지, 성능을 저하하는 부분이 있다. 이를 암호화/복호화를 이용해 정보를 검증하는 jwt로 보완할 수 있다.

jwt 구조

• header
  type,alg정보를 담고 있어 토큰이 무슨 타입인지, 어떤 알고리즘으로 해싱하는지의 정보를 담는다.
• payload
  토큰에 담을 정보들이 저장된다.
  {
  "userId : 1212123",
  "username: "meme"
  }
  위와 같이 사용자에 대한 일부 정보가 담기기도 한다.
• signature
  jwt 암호화의 중점인 부분이다.
  header, payload의 인코딩값을 합친 후 암호화해 결과를 생성한다.
  때문에 header, payload를 조금이라도 조작해 악의적 행위를 한다면
  서버는 signature가 예상과 달라지는 걸 통해 알 수 있다.

jwt에 대해 더 생각해 볼 점은 header,payload는 디코딩하면 누구나 볼 수 있는 정보이기에 변경할 시 알아챌 수 있더라도 정보가 노출되기는 한다는 것이다. 때문에 payload의 정보 또한 서버만 알아볼 수 있는 방식으로 작성되는 게 보안적으로는 좋을 듯 하다.