week02_KimJaeIn #11
Description
1. HTTP status code 에 대해서 자세히 알아오기
HTTP(하이퍼텍스트 전송 프로토콜) 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려준다.
응답은 5개 그룹으로 나뉨
▶정보를 제공하는 응답(1XX)
요청이 제공되었고 프로세스가 계속 진행 중임을 의미
▶성공적인 응답(2XX)
그것은 그 행동이 성공적으로 받아 들여지고, 이해되고, 받아 들여 졌음을 의미
▶리다이렉트(3XX)
이는 요청을 완료하기 위해 추가 조치가 취해 져야 함을 의미
▶클라이언트 에러(4XX)
요청에 잘못된 구문이 있거나 충족 될 수 없음을 의미
▶서버 에러(5XX)
이는 서버가 명백하게 유효한 요청을 이행하지 못했음을 의미
1xx : 정보
- 100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
- 101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
- 102(처리, RFC 2518)
2xx : 성공
- 200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
- 201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
- 202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
- 203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
- 204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
- 205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
- 206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
- 207(다중 상태, RFC 4918)
- 208(이미 보고됨, RFC 5842)
- 226 IM Used (RFC 3229)
3xx : 리디렉션
- 300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
- 301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
- 302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
- 303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
- 304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
- 305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
- 307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
- 308(영구 리다이렉션, RFC에서 실험적으로 승인됨)
4xx : 클라이언트 오류
- 400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
- 401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.[2]
- 402(결제 필요): 이 요청은 결제가 필요합니다.
- 403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
- 404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
- 405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
- 406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
- 407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
- 408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
- 409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
- 410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
- 411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
- 412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
- 413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
- 414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
- 415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
- 416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
- 417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
- 418(I'm a teapot, RFC 2324)
- 420(Enhance Your Calm, 트위터)
- 422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
- 423(잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
- 424(실패된 의존성, WebDAV; RFC 4918)
- 424(메쏘드 실패, WebDAV)
- 425(정렬되지 않은 컬렉션, 인터넷 초안)
- 426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
- 428(전제조건 필요, RFC 6585)
- 429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
- 431(요청 헤더 필드가 너무 큼, RFC 6585)
- 444(응답 없음, Nginx)
- 449(다시 시도, 마이크로소프트)
- 450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
- 451(법적인 이유로 이용 불가, 인터넷 초안)
- 451(리다이렉션, 마이크로소프트)
- 494(요청 헤더가 너무 큼, Nginx)
- 495(Cert 오류, Nginx)
- 496(Cert 없음, Nginx)
- 497(HTTP to HTTPS, Nginx)
- 499(클라이언트가 요청을 닫음, Nginx)
5xx : 서버 오류
- 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
- 501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
- 502(Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
- 503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
- 504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
- 505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
- 506(Variant Also Negotiates, RFC 2295)
- 507(용량 부족, WebDAV; RFC 4918)
- 508(루프 감지됨, WebDAV; RFC 5842)
- 509(대역폭 제한 초과, Apache bw/limited extension)
- 510(확장되지 않음, RFC 2774)
- 511(네트워크 인증 필요, RFC 6585)
- 598(네트워크 읽기 시간초과 오류, 알 수 없음)
- 599(네트워크 연결 시간초과 오류, 알 수 없음)
2. 암호화 방식 종류 알아오기. + bcrypt가 무엇인지 알아오기.
암호화 : 평문(해독 가능한 형태의 메시지)을 암호문(해독 불가능한 형태의 메시지)으로 변환하는 과정
복호화 : 암호문을 평문으로 변환하는 과정
▶ 대칭형 암호(비밀키 암호)
암호화 키와 복호화 키가 같다.
현재 가장 보편적으로 쓰이는 암호화 방식은 현 미국 표준 방식인 AES 이다.
AES는 128 ~ 256 비티의 키를 적용할 수 있어 보안성이 뛰어나며 공개된 알고리즘이라 누구나 사용 가능하다.
▶ 비대칭형 암호(공개키 암호)
암호화키와 복호화키가 다르다.
암호화를 하면 하나의 키 쌍이 생기고, 두 개의 키를 각각 키 A, 키 B라고 했을 때 키 A로 암호화한 암호문은 키 B로만 복호화 할 수 있고 키 B로 암호화한 암호문은 키 A로만 복호화 할 수 있다. 따라서 이 중 하나의 키만 비밀로 보호하고(이를 ‘비밀키’, ‘개인키’라고 한다.) 다른 하나의 키는 공중에게 공개해도 관계없다. 이렇게 둘 중 하나의 키는 반드시 공개되어야 통상적인 사용이 가능하므로 공개키 암호방식이라고 한다.
대칭형 암호는 훌륭한 암호화 방식이기는 하지만 결정적인 문제가 존재한다. 바로 '키 배송'에 관한 문제로, 어떻게든 송신 측에서는 수신 측에 암호 키를 전달해야만 하고, 이 키가 배송 과정에서 털리면 아무리 뛰어난 암호화 알고리즘을 사용했더라도 속절없이 평문이 털리게 된다. 안전하게 평문을 전달하기 위해 만든 것이 암호문인데, 정작 키는 안전하게 전달할 방법이 없는 것. 이 키 배송에 대한 방법은 여러 가지 방법이 연구되었지만 발상의 전환으로 키 배송 문제를 해결한 방식이 비대칭형 암호방식이다.
한데 비대칭형 암호는 암/복호화가 대칭형 암호에 비해 현저하게 느리다는 문제점이 있다. 따라서 현실적으로는 비대칭형 암호를 이용해서 대칭형 암호의 키를 배송하고 실제 암호문은 대칭형 암호를 사용하는 식으로 상호보완적으로 이용하는 것이 일반적이다.
▶ 단방향 암호
해싱(hashing)을 이용해 암호화를 하는 것으로 암호화/복호화와는 다른 개념이다.
해싱을 이용해 평문을 암호문으로 암호화하는 것은 가능하지만 암호문을 평문으로 복호화 하는 것은 불가능하다.
본적으로 동일한 평문은 동일한 암호문으로 암호화되지만 이를 바탕으로 평문을 복원 할 수는 없다. 복호화가 되지않는 것을 어떻게 암호화라고 할 수 도 있겠지만 실제로는 복호화하지 않아도 상관없는 정보가 있기 마련이다. 예를 들면 패스워드는 양방향 암호로 저장하는 것보다 단방향 암호로 저장하는 것이 안전하다. 암호화된 패스워드 목록이 유출된다고 해도 이를 가지고 원래의 패스워드를 복원할 수 없고, 패스워드 자체를 검증할 때는 입력받은 값을 암호화해서 암호화한 값끼리 비교하면 문제가 없기 때문이다.
- 해시를 이용한 암호화 기법 : 해시(Hash)함수(해시 알고리즘)를 이용하여 고정된 길이의 암호화된 문자열로 바꿔 버리는 것
- 해시 알고리즘 특징
해시 알고리즘 및 암호화 알고리즘은 종류가 다양하며, 알고리즘은 모두에게 공개되어있다.
해시 알고리즘마다 Hash 길이가 다르고 이미 보안이 뚫린 해시 함수가 존재한다.
해시 알고리즘은 특정 입력 대해 항상 같은 해시 값을 리턴한다.
해시된 값은 입력이 다른 값이지만 같을 수 있다.
※bcrypt
bcrypt는 Blowfish symmetric block cipher 알고리즘을 기반으로 설계부터 비밀번호 저장을 위한 목적으로 개발되었으며 오늘날까지 사용되는 가장 강력한 해시 기술 중 하나입니다. "Key Factor" 또는 "Work Factor"를 사용하여 하나의 해시 digest 생성하는 데 얼마만큼의 처리 과정을 수행할지 결정하며 이는 가장 주목할 기능입니다. 컴퓨터가 발전함에 따라 해싱의 속도도 더욱 좋아짐에 따라 "work factor" 를 조정하여 해싱의 속도를 느리게 함으로 오토 크래킹으로 부터 보안성을 높일 수 있습니다.
bcrypt는 애초부터 패스워드 저장을 목적으로 설계되었다. Niels Provos와 David Mazières가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이다. bcrypt는 보안에 집착하기로 유명한 OpenBSD에서 기본 암호 인증 메커니즘으로 사용되고 있고 미래에 PBKDF2보다 더 경쟁력이 있다고 여겨진다.
다만 PBKDF2나 scrypt와는 달리 bcrypt는 입력 값으로 72 bytes character를 사용해야 하는 제약이 있다.
3. middleware 에 대해서 알아오기
미들웨어는 운영 체제에서 제공되지 않는 서비스를 애플리케이션에 제공하는 다목적 소프트웨어입니다. 커널과 사용자 애플리케이션 사이에 있는 모든 소프트웨어를 미들웨어로 분류할 수 있습니다.
애널리스트이자 시스템 이론가인 Nick Gall은 "미들웨어는 소프트웨어에 관한 소프트웨어"라고 정의합니다. 미들웨어는 전통적인 애플리케이션의 기능을 제공하지 않으며 소프트웨어를 다른 소프트웨어에 연결합니다. 미들웨어는 하나의 애플리케이션에서 다른 애플리케이션으로 데이터가 흘러가게 하므로 IT 인프라의 배관이라 할 수 있습니다.
미들웨어는 운영 체제와 해당 운영 체제에서 실행되는 응용 프로그램 사이에 존재하는 소프트웨어입니다. 기본적으로 숨겨진 변환 계층으로 기능하는 미들웨어는 분산 응용 프로그램의 통신 및 데이터 관리를 가능하게 합니다. 데이터와 데이터베이스가 "파이프" 사이를 쉽게 통과할 수 있도록 두 가지 응용 프로그램을 함께 연결하기 때문에 배관이라고도 합니다. 미들웨어를 사용하면 사용자가 웹 브라우저에서 양식을 제출하거나 웹 서버가 사용자의 프로필을 기반으로 동적 웹 페이지를 반환하도록 요청할 수 있습니다.
모든 미들웨어가 통신 기능을 수행하지만 회사가 사용하기로 선택한 형식은 사용 중인 서비스와 통신해야 할 정보 형식에 따라 다릅니다. 여기에는 보안 인증, 트랜잭션 관리, 메시지 큐, 응용 프로그램 서버, 웹 서버 및 디렉터리가 포함될 수 있습니다. 미들웨어는 데이터를 앞뒤로 보내지 않고 실시간으로 발생하는 작업으로 분산 처리에도 사용할 수 있습니다.
※ 장점
- 표준화된 인터페이스 제공 가능
- 다양한 환경 지원, 체계가 다른 업무와 상호 연동이 가능
- 분산된 업무를 동시에 처리 가능하여 자료의 일관성이 유지
- 부하의 분산이 가능
※ 종류
- API(애플리케이션 프로그래밍 인터페이스)
API는 구현 방식을 알지 못해도 제품 또는 서비스가 서로 커뮤니케이션할 수 있도록 애플리케이션 소프트웨어를 구축하는 데 사용되는 툴, 정의, 프로토콜 세트입니다. - 애플리케이션 서버
Red Hat® JBoss® Enterprise Application Platform과 같은 애플리케이션 개발용 플랫폼입니다. 애플리케이션 서버는 애플리케이션을 만들고 이 애플리케이션을 실행하는 서버를 구축하는 기능을 제공하는 프레임워크입니다. - 애플리케이션 통합
애플리케이션 프레임워크는 통합 프레임워크를 통해 여러 애플리케이션의 데이터를 결합합니다. 이 프레임워크는 조직 전반에서 각 지점 간의 연결 수를 줄여 복잡한 종속성과 잠재적인 장애 지점이 발생하지 않도록 해줍니다. - 데이터 통합
데이터 통합은 이기종 소스의 데이터를 사용자가 액세스하고 조작할 수 있는 통합된 뷰에 결합하는 것입니다. - TP(트랜잭션 처리)
TP는 트랜잭션 애플리케이션을 제어하거나, 비즈니스 로직과 룰을 적용하거나, 데이터베이스 업데이트를 푸시하여 시스템(일반적으로 데이터베이스 또는 파일 시스템)의 무결성을 유지합니다. - RPC(원격 프로시저 호출)
클라이언트-서버 상호 작용을 통해 애플리케이션이나 기능을 여러 플랫폼 전체에 분산합니다. - MOM(메시지 중심 미들웨어)
큐 메커니즘을 추가하여 RPC를 개선함으로써 대상 노드가 느리거나 사용 중일 때 클라이언트서버 상호 작용이 비동기 방식으로 이루어지게 합니다. - ORB(오브젝트 리퀘스트 브로커)
또 다른 클라이언트-서버 상호 작용으로, 마치 로컬에 있는 것처럼 원격 서비스에 액세스할 수 있게 합니다. 서버는 ORB를 사용하여 레지스터를 처리하고 클라이언트는 ORB에 액세스하여 이 서비스를 찾습니다.