선장 일지

소켓이란?

• socket은 IP주소와 Port넘버가 합쳐진 네트워크 상에서 서버 프로그램과 클라이언트 프로그램이 통신할 수록 도와주는 소프트웨어 장치입니다.
• TCP/IP를 이용하는 API로 소프트웨어로 작성된 통신의 접속점입니다.
• 네트워크 상에서 서버와 클라이언트 프로그램이 특정포트를 통해 양방향 통신이 가능하도록 만들어주는 소프트웨어 장치입니다.
• 멀리 떨어져있는 두 호스트를 연결해주는 매개체 역할

spring 으로 socket programming 한 뒤 정리하자.

사용자가 마주하게 되는 곳

• 현재 사용자는 쇼핑몰 사이트나 처음 들어가는 사이트에서 로그인할 때 위의 사진과 같은 네모박스로 로그인할 수 있습니다.
• 이것을 가능하게 해준 것이 바로 OAuth입니다.

OAuth란?

• OAuth는 Open Authorization, Open Authentication 뜻하는 것으로 Service Provider 애플리케이션(네이버, 카카오, 구글)의 유저 비밀번호를 Third party 앱에 제공 없이 인증, 인가를 할 수 있는 오픈 스탠다드 프로토콜입니다.
• OAuth 인증을 통해 애플리케이션 API를 유저대신에 접근할 수 있는 권한을 얻을 수 있습니다.
• OAuth가 사용되기 전에는 외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 유저의 비밀번호가 노출될 가망성이 커서 보안상 취약한 구조였습니다.
• 그렇기 때문에 이 문제를 보안하기 위해 OAuth의 인증은 API를 제공하는 서버에서 진행하고, 유저가 인증되었다는 Access Token을 발급했습니다.
• 그 발급된 Access token으로 Third party(Consumer) 애플리케이션에서는 Service Provider의 API를 안전하고 쉽게 사용할 수 있게 되었습니다.

OAuth 동작 원리

• (A) (애플리케이션 → 사용자) 사용자 데이터에 접근하기 위한 권한을 요청합니다. 개념상 애플리케이션이 사용자에게 요청하지만, 실제 구현은 애플리케이션과 사용자 사이에 권한 제공기관이 중개 역할을 하는 경우가 일반적입니다.

• (B) (사용자 → 애플리케이션) 접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급합니다. RFC 6749에서는 4가지 유형의 권한 부여 동의서를 정의하고 있습니다. 애플리케이션과의 유형 및 권한 제공기관의 지원 여부에 따라 사용할 권한 부여 동의서의 유형이 결정됩니다.
• (C) (애플리케이션 → 권한 제공기관) 권한 부여 동의서를 제출하여 접근 토큰을 요청합니다. 접근 토큰은 사용자 데이터에 접근할 수 있는 키입니다.
• (D) (권한 제공기관 → 애플리케이션) 권한 부여 동의서를 확인하여 사용자가 동의한 데이터 항목, 범위 및 기간 등에 대한 정보가 담긴 접근 토큰을 제공합니다.
• (E) (애플리케이션 → 데이터 제공기관) 접근 토큰을 제출하여 사용자 데이터를 요청합니다.
• (F) (데이터 제공기관 → 애플리케이션) 사용자 데이터를 제공합니다. 이때 애플리케이션과이 제출한 접근 토큰이 유효함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목, 범위 및 유효기간이 정해집니다.

유니캐스트, 멀티캐스트, 브로드캐스트란?

• 네트워크에서 통신하는 방법을 구분짓는 방법입니다.

유니캐스트란?

• 1:1 전송 방식입니다.
• 데이터를 받고자하는 MAC Address를 프레임에 포함시켜 보내는 방식입니다.
• 그래서 MAC Address를 찾아 통신하게되고 네트워크에 있는 노드들 중 자신의 MAC Address인 경우에만 패킷이 CPU에 전송됩니다.
• 해당 안되는 다른 노드들에겐 CPU에 영향을 미치지않고 원하는 노드랑 통신하는 방법입니다.

브로드캐스트란?

• TCP/IP의 IPv4에서 같은 대역의 네트워크 주소를 가진 모든 호스트들에게 패킷을 전송하는 방식으로 하나의 네트워크와 전체의 통신 방법입니다.
• 같은 네트워크에 포함되는 장비들에게 거부권은 없고 무조건 수신하는 통신방법입니다.
• 유니캐스트와 다르게 무조건 받아들여야하기 때문에 CPU까지 패킷이 올라오게되고 컴퓨터 자체에 부담이 증가하게됩니다.
• 실질적인 통신은 IP Address가 아닌 MAC Address로 이루어지는데 IP 주소는 알고있지만 MAC Address를 모를 때 사용하는 방법입니다.
• 대표적인 예로 ARP(자신과 데이터 통신을 하기 위한 다른 노드의 MAC Address를 알아내기위한 프로토콜)

멀티캐스트란?

• 1:N 전송 방식입니다.
• 자신의 데이터를 받기 원하는 특정 호스트들에게 보내는 것이 가능하지만, 스위치나 라우터가 이 기능을 지원해 주어야 합니다.
• 유니캐스트로 일일이 보내거나 브로드캐스팅하기에 부담되는 경우 사용
• 전송을 위한 그룹 주소는 D Class IP 주소 (224.0.0.0 ~ 239.255.255.255)로 전세계 개개인의 인터넷 호스트를 나타내는 A, B, C Class IP 주소와는 달리 실제의 호스트를 나타내는 주소가 아니며, 그룹 주소를 갖는 멀티캐스트 패킷을 전송받은 수신자는 자신이 패킷의 그룹에 속해있는가를 판단해 패킷의 수용여부를 결정하게 됩니다
• 현재 인터넷상의 라우터들은 대부분 유니캐스트만을 지원하기 때문에 멀티캐스트 패킷을 전송하기 위해서 멀티캐스트 라우터 사이에 터널링이라는 개념을 사용하여 캡슐화된 패킷을 전송합니다.
• 즉 멀티캐스트 주소를 가진 데이터 패킷 헤더 앞에 멀티캐스트를 지원하지 않는 일반 라우터들을 거칠 경우, 기존의 유니캐스트 패킷과 같은 방법으로 라우팅되어 최종적으로 터널의 종착지 노드로 전송될 수 있게 하는 것 입니다.

DNS 란?

• 도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었습니다.
• 쉽게 생각하자면 사용자가 이해할 수 있는 도메인 이름을 기계가 이해할 수 있는 IP로 변환해주는 시스템입니다.

DNS 구성요소

• 도메인 네임 스페이스 (Domain Name Space)
  • 주소를 변환 시키기 위해 도메인 네임 스페이스의 트리구조에 대한 정보가 필요. 이 정보를 가진 서버 도메인 이름을 IP주소로 변환하는 것을 네임 서비스
• 네임 서버 (Name Server)
  • 최상위에 루트 DNS 서버가 존재하고 , 그 하위로 인터넷에 연결된 모든 노드가 연속해서 이어진 계층구조로 구성
• 리졸버 (Resolver)
  • DNS클라이언트의 요청을 네임 서버로 전달하고 네임 서버로부터 도메인이름과 IP 주소를 받아 클라이언트에게 제공하는 기능을 수행

DNS 동작원리

1. DNS Query (from Web Browser to Local DNS) : "제가 원하는 웹 사이트의 IP 주소를 알고 계신가요?" Local DNS 서버에게 전달
2. DNS Response (from Local DNS to Web Browser) : 만약 Local DNS 서버 캐시에 해당 Domain에 대한 IP가 있다면, 바로 IP 주소를 전달
3. DNS Query (from Local DNS to Root DNS) : Local DNS 서버 캐시에 해당 Domain이 없다면, "제가 원하는 웹 사이트의 IP 주소를 알고 계신가요?" Root DNS서버에게 전달
4. DNS Response (from Root DNS to Local DNS) : "저는 모르지만 , Com 도메인을 관리하는 네임서버의 이름과 IP 주소를 알려드릴 테니 거기에 물어보세요"
5. DNS Query (from Local DNS to com NS) : “ 안녕하세요. www. naver. com의 IP 주소를 알고 계신가요?"
6. DNS Response (from com NS to Local DNS) : "저는 모르지만 , Com 도메인을 관리하는 네임서버의 이름과 IP 주소를 알려드릴 테니 거기에 물어보세요"
7. DNS Query (from Local DNS to naver. com NS) : “ 안녕하세요. www. Naver .com의 IP 주소를 알고 계신가요?"
8. DNS Response (from naver .com NS to Local DNS) : "저는 모르지만 해당 웹은 www. g.naver. com이라는 이름으로 통해요. g.naver .com 도메인을 관리하는 네임서버의 이름과 IP 주소를 알려드릴테니 거기에 물어보세요"
9. DNS Query (from Local DNS to g.naver. com NS) : “ 안녕하세요. www. g.naver. com의 IP 주소를 알고 계신가요?"
10. DNS Response (from g.naver .com NS to Local DNS) : " 네 www. g.naver .com의 IP 주소는 222.222.222.22와 333.333.333.33입니다"
11. DNS Response (from Local DNS to Web Browser) : "네 www. naver .com의 IP 주소는 222.222.222.22와 333.333.333.33입니다"
12. 그 후, 3-way-handshake를 통해 통신하고 4-way-handshake를 통해 통신을 종료합니다.

REST와 RESTful

• 웹에 존재하는 사진, 영상, DB 자원 등 모든 자원에게 고유한 URI를 부여해 GET, POST, DELETE, PUT 명령어를 이용해 활용하는 것을 의미합니다.

Rest API의 네 가지 기능과 특징에 대해 말씀해주세요.

• GET : GET를 통해 해당 리소스를 조회하고 요청에 대한 자세한 정보를 가져옵니다
• POST : POST를 통해 해당 URI를 요청하면 리소스를 생성합니다
• DELETE : DELETE를 통해 리소스를 삭제합니다
• PUT : PUT를 통해 해당 리소스를 수정합니다. 여러 번 수행해도 결과가 같은 경우 사용합니다

URL과 URI의 차이

• URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성입니다. URL은 인터넷 상의 자원 위치를 나타내며 URI에 포함되는 개념입니다.

REST 란?

• Representational State Transfer(대표적인 상태 전달)
• 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍쳐의 한 형식
• REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
• REST는 네트워크 상에서 Client와 Server가 통신하는 방식 중 하나입니다.
• HTTP URI를 통해 자원을 명시하고, HTTP 메소드를 통해 해당 자원에 대한 CRUD Operation(Create, Read, Update, Delete)을 적용하는 것을 의미합니다.
• 즉, REST는 자원 기반 구조 설계의 중심에 Resource가 있고 HTTP 메소드를 통해 Resource를 처리하도록 설계된 아키텍쳐입니다.
• 웹 사이트의 이미지, DB, 텍스트 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여합니다.
• 장점
  1. 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해줍니다.
  2. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장합니다
  3. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다.
• 단점
  1. 브라우저를 통해 테스트 할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 헤더 값이 더 어렵게 느껴질 수 있습니다.
  2. 구형 브라우저가 아직 제대로 지원해주지 않는 부분이 존재합니다. (PUT, DELETE를 사용하지 못함)
• REST가 필요한 이유
  1. 애플리케이션 분리 및 통합
  2. 다양한 클라이언트의 등장
  3. 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이드, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 함
• REST 구성 요소
  1. 자원(Resource) : URI
     • 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재합니다.
     • 자원을 구별하는 아이디는 'groups/:group_id'와 같은 HTTP URI 입니다.
     • Client는 URI를 통해 자원을 지정하고 해당 자원 상태에 대한 조작을 서버에 요청합니다.
  2. 행위(Verb) : HTTP 메소드
     • HTTP 프로토콜은 메소드를 사용합니다.
     • HTTP 프로토콜은 POST, GET, PUT, DELETE, HEAD와 같은 메소드를 제공합니다.
  3. 표현(Representation Of Resource)
     • Client가 자원 상태에 대한 조작을 서버에 요청하면 서버는 요청에 대한 적절한 응답을 보냅니다.
     • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 표현으로 나타낼 수 있습니다.
     • JSON 혹은 XML을 통해 자원을 주고받는 것이 일반적입니다.
• REST 특징
  • Server-Client구조
  • Stateless (무상태)
  • Cacheable (캐시 처리 가능)
  • Layered System (계층화)
  • Code-On-Demand (optional)
  • Uniform interface (인터페이스 일관성)

RESTful 이란?

• 개념
  • RESTful이란 일반적으로 REST란 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다.
  • 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다. RESTful이란 REST를 REST답게 쓰기 위한 방법으로 누군가가 공식적으로 발표한 것은 아닙니다.
• 목적
  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
  • RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높여주는게 주 동기입니다. 그렇기때문에 퍼포먼스가 중요한 상황에서 굳이 REST API를 구현할 필요는 없습니다.
• RESTful하지 못한 경우
  • Ex1) CRUD 기능을 모두 POST로 처리하는 API
  • Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)

REST API

• REST기반으로 API를 구현하는 것
• 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API : 네이버 맵, 공공데이터 등등), 마이크로 서비스(하나의 큰 애플리케이션을 여러개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐) 등을 제공하는 업체 대부분은 REST API를 제공합니다.
• 특징
  • 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있습니다.
  • REST는 HTTP 표준을 기반으로 구현하므로 HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있습니다.
  • 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있습니다.
• 설계 (기본 규칙)
  1. URI는 정보의 자원을 표현해야 합니다.
     • resource는 동사보다 명사를 사용합니다.
     • resource는 영어 소문자 복수형을 사용하여 표현합니다.
     • Ex) 'GET /Member/1' -> 'GET /member/1'
  2. 자원에 대한 행위는 HTTP 메소드로 표현합니다.
     • URI에 HTTP 메소드가 들어가면 안됩니다.
     • Ex) 'GET /members/delete/1' -> 'DELETE /members/1'
     • URI에 행위에 대한 동사 표현이 들어가면 안됩니다.
     • Ex) 'GET /members/show/1' -> 'GET /members/1'
     • Ex) 'GET /members/insert/1' -> 'POST /members/1'
• 설계 규칙
  1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용합니다.
     • Ex) 'http://restapi.example.com/houses/apartments'
  2. URI에 마지막 문자로 구분자(/)를 포함하지 않습니다.
     • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야함
     • Ex) 'http://restapi.example.com/houses/apartments/ (X)'
     • REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않음
  3. 하이픈(-)은 URI가독성을 높이는데 사용합니다.
     • 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높임
  4. 밑줄(_)은 URI에 사용하지 않습니다.
     • 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않음
  5. URI 경로에는 소문자가 적합합니다.
     • URI 경로에 대문자 사용은 피하도록 함
     • RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
  6. 파일확장자는 URI에 포함하지 않습니다.
     • REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않음
     • Ex) `http://restapi.example.com/members/soccer/345/photo.jpg (X)`
     • Ex) `GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)`
     • Accept header를 사용
  7. 리소스 간에는 연관관계가 있는 경우
     • /리소스명/리소스 ID/관계가 있는 다른 리소스명
     • Ex) `GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)`
  8. :id는 특정 resource를 나타내는 고유 값
     • Ex) student를 생성하는 route: POST /students 
     • Ex) id=12인 student를 삭제하는 route: DELETE /students/12
•  

HTTP 프로토콜의 특징

• 비연결 지향(connectionless) : 클라이언트가 request를 서버에 보내고, 서버가 클라이언트 요청에 맞는 response를 보내면 바로 연결을 끊음
• 상태정보 유지안함(stateless) : 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않음

쿠키와 세션의 필요성

• HTTP 프로토콜은 위와 같은 특성으로 모든 요청 간 의존관계가 없음
• 즉, 현재 연결된 클라이언트가 이전의 연결된 클라이언트인지 아닌지 알 수 있는 방법이 없다.
• 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것이 큰 장점이지만, 통신할 때마다 새로 연결하기 때문에 클라이언트는 매 요청마다 인증을 해야한다는 단점이 있음.
• 이전 요청과 현재 요청이 같은 사용자의 요청인지 알기 위해서는 상태를 유지해야함
• HTTP 프로토콜에서 상태를 유지하기 위한 기술로 쿠키와 세션이 있다.

쿠키란?

• 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일이다.
• 이름, 값, 유효 시간, 경로 등을 포함
• 클라이언트의 상태정보를 브라우저에 저장하여 참조함
• 구성 요소
  • 쿠키의 이름(Name)
  • 쿠키의 값(Value)
  • 쿠키의 만료시간(Expires)
  • 쿠키를 전송할 도메인 이름(Domain)
  • 쿠키를 전송할 경로(Path)
  • 보안 연결 여부(Secure)
  • HttpOnly 여부(HttpOnly)
• 동작 방식
  1. 웹 브라우저가 서버에 요청
  2. 상태를 유지하고 싶은 값을 쿠키로 생성
  3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 쿠키를 포함해서 전송
     ```java
     Set-Cookie : id=doy
     ```
  4. 전달받은 쿠키는 웹 브라우저에서 관리하고 있다가 다음 요청 때 쿠키를 HTTP 헤더에 넣어서 전송
     ```java
     Cookie : id=doy
     ```
  5. 서버에서는 쿠키 정보를 읽어 이전 정보를 확인 후 응답
• 쿠키 사용 예 : 아이디, 비밀번호 저장, 쇼핑몰 장바구니

세션이란?

• 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술
• 즉, 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태
• 동작 방식
  1. 웹 브라우저가 서버에 요청
  2. 서버가 해당 브라우저(클라이언트)에 유일한 ID(세션 ID)를 부여
  3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 세션 ID를 포함해서 전송, 쿠키에 세션 ID를 JSESSIONID 라는 이름으로 저장
     ```
     Set−Cookie: JSESSIONID=xslei13f
     ```
     
  4. 웹브라우저는 이후 웹브라우저를 닫기까지 다음 요청 때 부여된 세션 ID가 담겨있는 쿠키를 HTTP헤더에 넣어서 전송
     ```
     Cookie: JSESSIONID=xslei13f
     ```
  5. 서버는 세션 ID를 확인하고 해당 세션에 관련된 정보를 확인 후 응답
• 세션 사용 예 : 로그인
• 세션도 쿠키를 사용하여 값을 주고 받으며 클라이언트의 상태 정보를 유지한다. 즉, 상태 정보를 유지하는 수단은 쿠키

쿠키와 세션의 차이점

• 저장 위치
  • 쿠키 : 클라이언트
  • 세션 : 서버
• 보안
  • 쿠키 : 클라이언트에 저장됨으로 보안에 취약함
  • 세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋음
• 라이프사이클
  • 쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있음
  • 세션 : 만료시간을 정할 수 있지만 브라우저를 종료하면 만료시간에 상관없이 삭제됨
• 속도
  
  • 쿠키 : 클라이언트에 저장되어 있어 서버에 요청시 빠름
  • 세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느림

HTTP Method 종류

• GET
• POST
• DELETE
• PUT

GET 메소드와 POST 메소드

• HTTP 프로토콜을 이용해서 서버에 데이터(요청 정보)를 전달할 때 사용하는 방식

GET 메소드 방식

• 개념
  • 정보를 조회하기 위한 메소드
  • 서버에서 어떤 데이터를 가져와 보여주기 위한 메소드
  • 가져오는 것(Select)
• 사용 방법
  • URL 끝에 '?'가 붙고, 요청 정보가 (key=value)형태의 쌍을 이루어 ?뒤에 붙여서 서버로 전송
  • 요청 정보가 여러개 일 경우 '&'로 구분
  • ex) 127.23.123.323?name1=value1&name2=value2
• 특징
  • URL에 요청 정보를 붙여서 전송
  • URL에 요청 정보가 뒤에 붙기때문에 요청 길이에 대해 제한이 있어서 대용량의 데이터를 전송하기 어려움
    • 한 번 요청 시 전송 데이터(주소값 + 파라미터)의 양은 255자로 제한됩니다.(HTTP/1.1은 2048자) 
  • 요청 정보를 사용자가 쉽게 확인할 수 있음
    • 그렇기때문에 보안에 취약합니다.
  • HTTP 패킷의 body는 비어있는 상태로 전송
    • 즉, Body의 데이터 타입을 표현하는 'Content-Type' 필드도 HTTP Request Header에 들어가지 않음
  • POST 방식보다 빠름
    • GET방식은 캐싱을 사용할 수 있다. GET 요청과 그에 대한 응답이 브라우저에 의해 캐싱

POST 메소드 방식

• 개념
  • 서버의 값이나 상태를 바꾸기 위한 용도의 메소드
  • 수행하는 것 (Insert, Update, Delete)
• 사용 방법
  • 요청 정보를 HTTP 패킷의 body안에 숨겨서 서버로 전송
  • Form 태그를 이용하여 submit하는 형태
  • Request Header의 Content-Type에 해당 데이터 타입이 표현되며, 전송하고자하는 데이터의 타입을 적어줘야함
    • Default : application/octet-stream
    • 단순 텍스트의 경우 : text/plain
    • 파일의 경우 : multipart/form-date
• 특징
  • Body안에 요청 하는 데이터를 숨겨서 전송하기 때문에 보안상 GET방식보다 안전하고, 대용량의 데이터를 전송할 수 있음
  • 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고, 이를 받은 서버쪽이 데이터를 디코딩

PUT 메소드 방식

• 개념
  • 리소스를 생성 / 업데이트하기 위해 서버로 데이터를 보내는 데 사용
• 사용 방법
  • POST 방식과 비슷하지만 이미 있는 값의 UPDATE를 할 때 사용하여 Idempotent합니다.
• 특징
  • 여러 번 요청해도 동일한 결과입니다. (Idempotent, 멱등)
  • Body의 수정할 값을 넣어서 서버로 전송합니다.

DELETE 메소드 방식

• 정의
  •  지정된 리소스를 삭제합니다.
• 사용방법
  • GET과 비슷한 방식으로 URL에 삭제할 데이터를 파라미터에 추가하여 서버에 전송합니다.
• 특징
  • Body에 삭제할 데이터를 넣는 것이 아닌 URL에 포함시켜 전송합니다.

Q. 조회하기위한 용도로 사용할 때 POST가 아닌 GET 방식을 사용하는 이유?

1.  설계원칙에 따라 GET방식은 서버에게 여러번을 요청해도 동일한 응답이 돌아와야함.(Idempotent, 멱등)
   • GET방식은 가져오는 것(Select)로, 서버의 데이터나 상태를 변화시키지 않아야함.
     • ex) 게시판의 리스트, 게시글 보기 기능
     • 예외) 방문자의 로그 남기기, 글을 읽은 횟수 증가 기능
   • POST방식은 수행하는 것으로, 서버의 값이나 상태를 바꾸기 위한 용도
     • ex) 게시판의 글 쓰기 기능
2. 웹에서 모든 리소스는 Link할 수 있는 URL을 가지고 있어야함.
   • 어떤 웹페이지를 보고 있을 때 다른 사람한테 그 주소를 주기 위해서 주소창의 URL을 복사해서 줄 수 있어야 함.
   • 즉, 어떤 웹페이지를 조회할 때 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크의 정보가 필요
   • 이때 POST 방식을 사용할 경우에 값(링크의 정보)이 Body에 있기 때문에 URL만 전달할 수 있으므로 GET 방식을 사용해야 함. 그러나 글을 저장하는 경우 URL을 사용할 필요가 없기때문에 POST 방식을 사용함.

HTTP란?

HTTP는 www(world wide web)상에서 주고받을 수 있는 포로토콜입니다.

주로 html 문서를 주고받을 때 쓰입니다. TCP와 UDP를 사용하며, 80번 포트를 사용합니다.

HTTP1과 HTTP2의 차이

• HTTP1과 HTTP2의 가장 큰 차이점은 속도가 향상 되었다는 점입니다.
• 한번의 요청에 하나의 리소스만 받고 한 요청의 지연되면 뒤이은 요청들도 지연되는 특성을 가졌던 전 버전과 달리 스트림이라는 개념이 추가되어 한번에 다수의 요청과 응답을 처리하는 구조로 바뀐 차이점이 있습니다. 또한, 쿠키를 담아 큰 헤더를 가졌던 이전 버전과 달리 쿠키들을 허프만 코딩 압축을 통해 크기 자체를 압축시켰습니다.
• HTTP1은 하나의 요청에 하나의 리소스만 처리하기 때문에 동시전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈가 있었습니다.
  • 서버와 클라이언트가 1번 요청에 1개의 리소스만 받아 처리하기 때문에 처리속도가 느리다.
  • 쿠키가 헤더에 포함되어 크기가 큰 것도 속도가 느린 이유이다.
• HTTP2가 HTTP1보다 속도가 빠른 이유
  • Multiplexed streams : 1번에 다수의 요청과 응답을 처리할 수 있습니다.
  • Server Push : 클라이언트가 서버에 요청하지 않아도 서버측에서 알아서 리소스를 보내줍니다.
  • Header compression : 허프만 코딩으로 쿠키의 크기를 압축하여 줄였습니다.

HTTP Method

• GET : 입력 값으로 데이터를 바꾸지않고 리소스를 보여주기만 하는 용도일 때 사용하며 주소창에 입력한 값들이 포함되어 나옵니다.
• POST : 입력 값으로 데이터를 저장, 업데이트 작업을 할 때 사용하며 주소창에 입력한 값들이 포함되어 나오지 않습니다. 
• PUT : POST와 같은 역할을 하지만, POST와 달리 요청할 때 식별자를 보내야하며 몇 번을 수행해도 같은 값을 보장받고 싶을 때 사용합니다.
• DELETE : 데이터를 삭제할 때 사용합니다.
• HEAD
• OPTIONS
• TRACE
• CONNECT

HTTP와 HTTPS

HTTP와 HTTPS는 HTML 같은 문서를 웹 브라우저가 웹 서버에 요청하는 프로토콜이라는 점이 같지만 통신 내용을 암호화하는 것이 다릅니다.

HTTPS의 S는 Secure socket, 즉 안전한 통신망이라는 뜻으로 페이지 암호화 키를 공개키로 암호화하고 인증하는 것입니다. 여기서 공개키란 데이터를 암호화하는데 키가 2개 필요하는 것입니다.

HTTP (HyperText Transfer Protocol)

• 웹 상에서 클라이언트와 서버가 요청/응답(request/response)으로 정보를 주고 받을 수 있는 프로토콜(웹 통신 프로토콜)
• 주로 html 문서를 주고받을 때 사용합니다.
• TCP와 UDP를 사용하며, 80번 포트를 사용합니다.
• 아무나봐도 상관없는 페이지에 HTTP를 사용합니다. (보안을 붙이지 않았기때문에 HTTPS보다 빠릅니다.)
• 비연결(connectionless) : 클라이언트가 서버에 요청을 보내고 서버에서 적절한 응답을 클라이언트에게 보내면 연결은 바로 끊어집니다.
• 무상태(stateless) : 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않습니다.

HTTPS (HyperText Transfer Protocol over secure Socket layer)

• HTTP over TLS, HTTP Secure, HTTP over SSL
• HTTP의 보완이 강화된 버전의 프로토콜
• HTTPS의 기본 포트는 TCP/IP로 443번 포트를 사용합니다.
• HTTPS는 소켓 통신에 일반 텍스트를 이용하는 대신에, 웹 상에서 정보S를 암호화하는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화합니다.
• TLS(Transport Layer Security) 포로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것 입니다.
• 두 프로토콜의 주 목적은 기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것 입니다.
• 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있습니다.
• 금융 정보나 메일 등의 중요한 정보를 주고 받는 것에 HTTPS를 사용합니다.

HTTPS가 필요한 이유

• 클라이언트인 웹 브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공합니다.
• HTTP를 통해 웹 페이지(HTML or 텍스트 정보)를 교환합니다.
• 이때, 주고받는 데이터에 주민번호나 비밀번호와 같은 중요한 정보가 포함된 상태로 네트워크상에서 제 3자가 정보를 가로챈다면 보안상 큰 위험이 있을 수 있습니다. 그래서 중간에서 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용합니다.
• HTTP를 사용할 경우 개인 정보가 아니더라도 사용자가 어느 사이트에 접근하는 지, 어떤 행동을 하는지 모두 감시할 수 있습니다. 이로 인해 정부나 ISP 가 사용자의 패턴을 파악해서 인터넷 검열을 할 수 있다는 문제가 있습니다.

HTTPS의 원리

• 공개키, 개인키 알고리즘 방식
• 암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법
  • 공개키 : 모두에게 공개, 공개키 저장소에 등록
  • 개인키(비공개키) : 개인에게만 공개. 클라이언트-서버 구조에서는 서버가 가지고 있는 비공개키
• 클라이언트 -> 서버
  • 사용자의 데이터를 공개키로 암호화 
  • 서버로 전송 (데이터를 가져가도 개인키가 없기 때문에 복호화할 수 없음)
  • 서버에서 개인키로 복호화하여 요청 처리

HTTPS의 장점

• 네트워크 상에서 열람, 수정이 불가하므로 안전합니다.

HTTPS의 단점

• 암호화하는 과정이 웹 서버에 부하를 줄 수 있습니다.
• HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 발생합니다.
• 암호화, 복호화를 하기때문에 HTTP보다 느립니다.
• 인터넷 연결이 끊긴 경우 재인증 시간이 소요됩니다.
  • HTTP는 비연결형으로 웹 페이지를 보는 중 중간에 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있습니다.
  • 그러나 HTTPS의 경우 소켓(데이터를 주고받는 경로) 자체에서 인증하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 인증이 필요합니다.

대칭키 암호화, 공개키 암호화 방법

• 대칭키 암호화는 암호화 키와 복호화 키가 동일한 암호화 기법입니다. 암호키 자체가 암호화 되지 않은 평문으로 노출되면 보안에 매우 최악하여 키 전달 및 관리가 어려운 단점이 있고, 공개키 암호화 방식보다 속도가 빠르다는 장점이 있습니다.
  • 대칭키
  • 암/복호화 키가 동일
  • 대표 암호알고리즘 : DES, 3DES, TDES, AES, SEED, ARIA 등
  • 대체적으로 bit 수가 적고 수행시간이 짧다.
  • 사용에 제한적입니다.
  • 사용 예 :  디스크 암호화
• 공개키 암호화는 대칭키 암호화와 다르게 개인키와 공개키 두 가지 키를 사용합니다. 개인키로 암호화된 문서는 공개키로만 복호화할 수 있으며, 반대로 공개키로 암호화된 문서는 개인키로만 복호화할 수 있습니다. 암호화, 복호화의 작업이 복잡하기 때문에  대칭키 암호화에 비해 시간이 오래 걸린다는 단점이 있습니다.
  • 비대칭키(공개키, 개인키)
  • 암/복호화 키가 다름
  • 대표 암호 알고리즘 : RSA, ECC 등
  • 대체적으로 bit 수가 많고 수행시간이 길다.
  • 공개라는 단어와 어울리게 범용적으로 사용 가능합니다.
  • 사용 예 : 비밀번호 암호화
• 요즘 암호화 통신에서는 대칭키 암호화와 공개키 암호화의 좋은 점을 채택하여, 공개키 암호화를 사용하여 대칭키 암호화의 공통키를 공유하고, 그 키를 기반으로 실제 통신을 암호화하는 하이브리드 구조를 사용합니다.

SSL과 TLS (https://nuritech.tistory.com/25 - 조금 더 딥하게 정리되어 있습니다.)

• SSL과 TLS는 클라이언트와 서버간의 통신을 암호화하는데 사용되는 프로토콜입니다.
• SSL은 인터넷을 통해 전달되는 정보의 보안을 위해 개발한 인터넷 통신 규약 프로토콜이며, TLS는 안정성을 높이는 목적으로 SSL 3.0을 기초로하여 고안되었습니다.
• 과정 : SSL/TLS는 TCP 레벨의 연결이 완료된 후에 다음과 같은 방법으로 동작합니다. (SSL handshake) 
  • 클라이언트와 서버가 기본적인 hello 메세지로 정보 송수신
  • 서버는 서버가 사용하는 SSL/TLS 인증서 전달
  • 클라이언트는 암호화에 사용할 키(대칭키 or 공개키)를 서버에 전달
  • 클라이언트는 암호화에 사용할 암호 알고리즘과 해시 알고리즘을 서버에 전달
  • 서버도 알고리즘 목록을 교환하여 키를 서버와 클라이언트 모두 소유