ASP.NET 응답없음 =
http://support.microsoft.com/kb/196271
IIS Diagnostics Toolkit = http://blog.happygom74.com/tag/Diagnostics
IIS 웹 서버 체크 리스트 =
.NET Application의 Memory Leak, Application Hang 발생 원인 및 추론 방법 =
Process Explorer = |
괜찮은 디버깅 관련 내용
2012. 1. 31. 13:18
[javascript] jQuery Address 1.4 - jQuery plugin
2012. 1. 4. 09:25
Present 선물
2011. 12. 28. 18:11
현재(Present)는 선물(Present)입니다. ? 작가미상
매일 아침 당신에게 86,400원을 입금해주는
은행이 있다고 상상해 보세요.
그 계좌는 당일이 지나면 잔액이 남지 않습니다.
매일 저녁 당신이 그 계좌에서 쓰지 못하고
남은 잔액은 그냥 지워져 버립니다.
당신이라면 어떻게 하시겠습니까?
당연히 !!! 그 날 모두 인출해야겠죠.
시간은 우리에게 마치 이 은행의 계좌와도 같습니다.
매일 아침, 우리는 86,400초라는 시간을 받고
매일 밤 우리가 좋은 목적으로 사용하지 못하고
버려진 시간은 그냥 없어져버릴 뿐입니다.
잔액은 더 이상 없습니다.
더 많이 사용할 수도 없습니다.
매일 아침, 은행은 당신에게 새로운 돈을 넣어 줍니다.
매일 밤, 그 날의 남은 돈은 남김없이 불살라 집니다.
그 날의 돈을 사용하지 못했다면 손해는 오로지 당신이 보게 되는 겁니다.
시간은 아무도 기다려주지 않습니다.
오늘이야말로 당신에게 주어진 선물입니다.
원도우 성능모니터 중요 카운터 소개
2011. 12. 14. 19:40
웹서버 용량 증설 계획 및 성능 측정이 필요한 경우 아래 항목을 유심히 살펴 보고 로그를 통해서 모니터링하여 판단 할 수 있는
근거 데이터로 활용 할 경우 유용하겠다.
아래 내용하고 비슷한 참고 사이트 주소 : http://tiger5net.egloos.com/5096569
1. 메모리 사용량
Memory: Available Kbytes
사용 가능한 메모리량: 5000KB 이상 권장
Memory: Page Faults / Sec
초당 시스템에서 일어나는 페이지 오류의 평균적인 수
0에 가까울수록 좋다.
초당 2 이상의 페이지 오류가 발생하면 메모리를 추가해야 한다.
Memory: Pages / Sec
초당 시스템에 의해 디스크에서 읽거나 디스크로 쓴 페이지 평균값
5보다 작을 것을 권장함.
Memory: Cache Fault / Sec
Cache Fault는 Cache Manager가 즉각적인 캐시에서 페이지를 찾지 못할 때 발생
Process : Working Set / SQL Server 인스턴스
SQL 서버가 사용하는 메모리량: 5MB 보다 높아야 한다.
2. CPU 사용량
Processor: %Processor Time
CPU 사용율: 75%가 넘지 않아야 한다. (지수증가)
Processor: %User Time
응용프로그램이 사용한 CPU 사용률
System: Processor Queue length
프로세서 대기열에 있는 스레드 수: 2보다 작아야 한다.
System: Context Switches / Sec
컴퓨터의 모든 프로세서가 한 스레드에서 다른 스레드로 전환한 전체 횟수
CPU 당 5000 이 넘게 되면 Resource Contention Problem.
3. Physical Disk
Physical Disk: %Disk Time (Physical % Logical)
지속적인 시간 동안 55%를 넘지 않아야 한다.
Physical Disk: Avg. Disk Queue Length
대기열의 대기수: 최고 2를 넘지 않을 것을 권장.
Physical Disk: Avg. Disk Read Queue Length
대기열의 읽기요청 대기수
Physical Disk: Avg. Disk Write Queue Length
대기열의 쓰기요청 대기수
4. SQL 성능
SQL Server: Cache Manager / Cache Hit Ratio
캐쉬 적중률:90% 이상 권장 (미만시 메모리 추가, OLTP 시스템에서는 99% 권장)
SQL Server: Buffer Manager / Buffer Cache Hit Ratio
캐쉬 적중률:90% 이상 권장
SQLServer: Databases / Transactions/sec
데이터베이스에있는 모든 데이터 파일의 총 크기
SQLServer: Buffer Manager / Checkpoint pages/sec
검사점에의한 플러시된 페이지수
SQLServer: Access Methods / Skipped Ghosted Records/sec
고스트 레코드수
SQLServer: Access Methods / Page Splits/sec
페이지 스플릿 발생횟수
SQLServer: SQL Statistics / SQL Compilations/sec
초당 컴파일수
SQL Server General Statistics / User Connections
현재 연결된 사용자수: Maximum Worker Threads =255
다음은 계속적으로 모니터링하는 일반적인 성능 카운터입니다. 특정한 값이 한계에 도달하거나 유지되는 것을 관리자에게 알리도록 경보/경고를 설정할 수 있습니다.
Active Server Page, Requests Queued
이것은 대기열에서 서비스를 기다리는 요청 수를 모니터링합니다. 스트레스 상황에서 지연된 요청 수가 상당히 증가할 경우 프로세서 사용률은 비교적 낮게 남아있고 이것은 스크립트가 처리할 수 있는 것보다 많은 호출을 수신하는 COM 개체를 호출하고 있다는 표시입니다. 이러한 경우에 ASP에서 호출된 COM 개체는 일반적으로 장애가 됩니다. 사이트 개발자에게 알려주십시오.
Memory: Page Faults/sec.
5초 이상 지속되는 하드 페이지 실패는 RAM이 부족하다는 메시지로 중요한 표시입니다. 메모리 장애를 나타내는 다른 카운터로 Memory:Pages Input/sec, Memory:Page Reads/sec 및 Memory:Pages/sec을 들 수 있습니다.
Memory: .
시스템 운영에서 사용 가능한 실제 총 메모리를 측정하고 서버에서 모든 프로세스와 응용 프로그램을 실행하는데 필요한 메모리와 비교하십시오. 적어도 최고 사용 상태에서 사용할 수 있는 메모리의 10%를 유지하십시오. 기본적으로 IIS 5.0은 서버 컴퓨터에서 다른 응용 프로그램을 실행하는데 사용할 수 있는 메모리의 나머지를 남겨두고 파일 캐시에서 사용할 수 있는 메모리의 50%까지 사용한다는 점을 유의하십시오. 이것이 지속적으로 4MB 이하로 떨어지면 더 많은 메모리의 설치를 심각하게 고려해봐야 합니다.
Memory: Committed Bytes.
최고 작업 기간 동안 허용하는 비교치를 특정 시간 동안 추적해야 합니다. 적어도 4MB의 메모리 또는 커밋된 메모리가 사용할 수 있는 메모리의 5% 이상이 항상 있어야 합니다.
SQLServer: Cache Hit Ratio.
이것은 SQL 서버가 디스크에 액세스하는 것에 대한 캐시에서 데이터를 찾는 시간에 대한 비율입니다. 80%보다 적은 캐시 적중률은 SQL Server에 RAM이 부족함을 나타냅니다. 시스템에 RAM이 많이 있다고 해도 SQL Server에 충분한 RAM이 할당되지 않았다면 이러한 문제가 발생할 수 있습니다. SQL Server에 보다 많은 RAM을 제공하려면 sp_configure 저장된 프로시저 및 SQL Server Enterprise Manager(Sqlew.exe)를 사용하십시오.
Physical Disk: >% Disk Time.
선택한 디스크가 읽기 및 쓰기 요청을 제공하는데 사용되는 경과 시간 비율입니다. Physical Disk와 함께 Avg. Disk Queue Length는 디스크 드라이브 장애를 나타내는 중요한 표시입니다. 명령줄 유틸리티 Diskperf ?y를 실행한 후에 디스크 카운터를 추적해야 합니다.
Physical Disk: Avg. Disk Queue Length.
디스크가 읽기와 쓰기 요청을 수용할 정도로 빠르지 않으면 해당 요청은 대기열에 넣게 됩니다. Physical Disk: % Disk Time은 85% 이상이고, Avg. Disk Queue Length는 둘 이상이고, RAM의 부족으로 디스크 작업이 이루어질 수 없는 경우 디스크에 병목 현상이 발생할 수 있습니다. Physical Disk에 포함된 디스크 트래픽을 관찰할 수 있는 다른 카운터로 Disk Reads/sec, Physical Disk, Disk Writes/sec, and SQLServer, Log Writes/sec 등을 들 수 있습니다.
RAID 시스템과 같은 디스크 시스템에 보다 많은 물리적 드라이브의 추가를 고려해보십시오. 이것은 읽고 쓸 수 있는 스핀들 수뿐만 아니라 데이터 전송률 속도도 향상시켜 줍니다.
System: >% Total Processor Time.
이것은 프로세서가 사용 중인 시간에 대한 비율입니다. 이 카운터가 지속적으로 80%와 100% 사이에서 실행되고 있을 때 CPU 병목 현상의 중요한 표시가 됩니다. 보다 많은 프로세서의 설치를 고려하십시오.
System: Processor Queue Length.
이것은 프로세서 주기를 기다리며 대기하는 스레드 수의 순간적인(평균이 아닌) 계산입니다. 둘 이상으로 지속되는 프로세서 대기열 길이는 일반적으로 프로세서 정체를 나타냅니다. 보다 많은 프로세서의 설치를 고려하십시오.
SQLServer -Locks: Total Blocking Locks.
차단 잠금 수가 높으면 데이터베이스에서 핫스폿을 나타냅니다. 사이트 개발자에게 알려주십시오.
Process: Private Bytes.
이 프로세스가 할당한 현재 바이트 수는 다른 프로세스와 공유할 수 없습니다. 시스템이 특정 시간 동안 성능이 떨어지는 경우에 이 카운터는 메모리 누출의 좋은 표시가 될 수 있습니다. 사이트 개발자에게 알려주십시오.
Thread: Context Switches: sec: Inetinfo =>Thread#.
프로세서 당 스레드 또는 스레드 풀의 최대 수를 측정합니다. 너무 많은 컨텍스트 전환을 하지 않았는지 확인하려면 이 카운터를 모니터링해야 합니다. 컨텍스트 전환에서 손실한 메모리는 성능이 향상되기 보다는 감소하는 위치에 추가되는 스레드의 이점을 허용합니다. 초 당 15,000개 이상의 컨텍스트 전환에 대해서는 심각하게 고려해야 합니다.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o />
시스템 모니터 시 사용되는 대표적인 개체를 몇 가지 정리했습니다.
Processor 개체
1. % PROCESS Time : 프로세서가 스레드를 실행하는 시간의 백분율, 이 값은 100%에서 유휴프로세서의 비율을 빼서 계산된다.
2. % Privileged Time : 프로세서가 특권모드 (운영체제 기능을 수행하고 드라이버를 실행하는 모드)에서 작업한 시간의 백분율. 이 값이 높으면 I/O처리를 위해 시스템 인터럽트가 많이 발생하고 있음을 의미하므로, interrupts/sec카운터를 monitoring해야 한다.
3. % User Time : 프로세서가 사용자 모드에서 작업한 시간의 백분율. 이러한 작업 형태는 응용 프로그램에 의해 발생된다. 일반적으로 % User Time값을 최대화하고 % privileged Time 값은 최소화하는 것이 바람직하다.
4. % Interupt Time : 프로세스가 하드웨어 인터럽트를 처리하는 데 소비된 시간의 백분율, 이러한 interupt는 os 동작의 일부로 간주한다.
5. interrupts/sec : 프로세스가 받아서 처리한 초당 하드웨어 인터럽트 수 ,과도한 인터럽터가 발생하면 PhysicalDisk의 객체카운터를 monitoring할 것, (PhysicalDisk의 문제라면 최신의 디스크 컨트롤러 드라이버를 가지고 IO 대역폭을 늘림으로써 과도한 인터럽트를 줄일수 있다.)
SYSTEM 개체
1. Processor Queue Length : 이 카운터는 프로세서를 얻기 위해 큐에서 대기하는 쓰레드 수를 나타낸다. 다. 즉 실행되기 위해 대기하고 있는 스레드 수를 나타내는 것이다. 시스템에 다중 프로세서를 가지고 있다해도 모든 스레드는 프로세서 시간을 얻기위해 대기하는 하나의 큐만을 가진다. 이 카운터는 실행준비가 되었지만 대기하는 스레드만을 계산하며 현재 실행되고 있는 스레드는 계산하지 않는다. Processor Queue Length 값이 프로세서 당 2보다 크면 cpu 병목을 가지고 있는 것이므로, 더 많은 프로세서를 추가하거나 더 빠른 프로세서로 교체 또는 시스템의 작업 부하를 줄임으로써 이러한 조건을 완화시킬수 있다. 또한 쿼리 튜닝이나 인덱스 전략 또한 해결 책 중에 하나이다.
2. Context Switches /sec : 컨텍스트 전환은 프로세서에서 운영체제나 응용 프로그램이 하나의 스레드를 실행하다가 강제적으로 다른 스레드의 실행으로 전환될 때 발생한다. 멀티 스레드 응용 프로그램을 실행하는 다중 프로세서 시스템에서는 항상 어느 정도의 컨텍스트 전환을 보게 될 것이지만, 초당10,000이상의 컨텍스트 전환이 발생하면 주의하여야 한다.
SQL server : Buffer Manager 개체
1. Buffer Cache Hit Ratio : 현재 버퍼 캐시에 위치한 페이지에서 참조한 요청의 백분율. 페이지가 이미 메모리(버퍼 캐시 내부)에 있으면 SQL server는 디스크 서버시스템에서 읽어오기 위해 물리적 I/O를 요청할 필요가 없다. 물리적 I/O에 비교하면 메모리 I/O는 상대적으로 적게 발생하기 때문에, 높은buffer cache hit ratio는 시스템 성능과 처리량 증가와 관련된다. 잘 튜닝된 시스템은 90% 이상의 값을 가진다. Buffer cache hit ratio 값이 작으면 sql server에 더 많은 메모리를 할당하도록 한다. 모든 현재 메모리가 이미 sql server에 할당 되었다면 시스템의 물리적 메모리 양을 늘려야 한다.
2. Procedure cache Pages : 컴파일된 쿼리와 저장 프로시저를 저장하기 위해 Sql Server에 의해 사용된 페이지 수. 이 수에 8kb를 곱하면 사용중인 양을 Kb로 알수 있다.
3. Free Pages : 할당되지 않은 sql server 메모리 버퍼수 (8kb 페이지로). 이 값이 지속적으로 작거나 0이면 서버에 메모리가 작음을 나타내는 것이다. 이 상황을 완화하려면 메모리 할당을 증가시키거나 물리적으로 메모리를 추가시켜야 한다.
4. Page Reads/sec : Sql server에서 발급한 초당 물리적 데이터베이스 페이지의 읽기 요청 횟수. 시스템이 안정상태에 이를 때까지 page reads/sec카운터 값이 높은 것을 볼 수 있다. 그러나 많은페이지가 메모리에 읽혀져 캐시 히트로 다시 액세스된다면 페이지 읽기 수는 감소하게 된다. 이 값이 지속적으로 높게 유지되면 sql server의 메모리 할당을 증가시키거나, 시스템에 물리적 메모리를 추가하거나 또는 쿼리를 튜닝하여야 한다.
5. Stolen Pages : 이 카운터는 시스템의 다른 응용 프로그램의 요구를 충족시키기 위해 얼마나 많은 8kb 크기 페이지들이 SQL server데이터 캐시로부터 제거되었는지를 나타낸다. Win2k는 이 제거된 메모리를 다른 시스템 구성 요소의 요구조건을 만족시키기 위해 다시 할당하게 된다. Min server memory를 높이는 것이 stolen pages의 카운터의 수를 떨어뜨릴 수 있는 방법이나 이렇게 되면 다른 응용프로그램이 메모리 할당을 받지 못해 전체적으로 시스템이 늦어지는 현상이 발생할 수 있다. 이럴 때의 유일한 해결책은 시스템의 메모리를 추가해야 한다.
6. page Writes / sec : Sql server에 의해 발급된 초당 물리적 데이터베이스 페이지의 쓰기 수
SQLServer : Databases 개체
1. Log Flush Waits/sec : 로그 플러쉬는 로그 버퍼에 있는 데이터가 물리적 로그 파일로 플러쉬될 때 발생한다. 즉 로그 플러쉬를 대기하는 데이터베이스 커밋 수를 말하는 것이다. 데이터베이스 페이지의 무결성을 유지하기 위해 변경된 데이터 페이지는 로그버퍼가 디스크에 flush될 때까지 데이터 파일 디스크로 기록될 수 없다. 즉 로그버퍼가 로그 파일에 플러쉬 되어야 트랜잭션은 커밋될 수 있고 dirty page도 테이터 디스크에 기록될 수 있다. 커밋이 로그 플러쉬를 기다릴 때 로그 디바이스에는 일반적으로 병목이 발생하는데, 로그 디바이스의 I/O 대역폭을 늘림으로써 이 조건은 쉽게 치료할 수 있다. (로그 파일을 위해 사용되는 컨트롤러의 쓰기 캐시를 활성화 시키거나 로그 파일이 존재하는 디스크 드라이버의 속도를 늘릴 수 있다)
2. Percent Log Used : Sql server가 사용하고 있는 현재 정의된 로그 공간의 퍼센트. 이 카운터 차트는 로그 파일이 얼마나 빨리 증가하는지 언제 파일이 짤려졌는지(로그 백업 명령의 결과로 나타날 수 있으며, 백업이 완료되면 로그를 잘라낸다)를 보여준다.
SqlServer : General Statistics 개체
1. user connections : Sql Server로의 현재 사용자 연결 수. 정기적으로 이 카운터를 모니터링하면 사용자 동작에 있어서의 경향을 파악할 수 있고(이를 테면 사업 성장) 사용자 연결이 어떤 비율로 증가하였는지를 알 수 있다.
SQLSEVER:Latches 개체
Latch는 트랜잭션 도안 잠금을 걸 필요가 없는 동작을 보호하는 단기간의 동기화 개체이다. 관계 엔진(Relational Engine)은 쿼리를 처리할 때, 베이스 테이블이나 인덱스로부터 행이 필요할 때마다 스토리지 엔진에 행을 반환하도록 요청한다. 스토리지 엔진이 행을 Db엔진에 전송할 때 스토리지 엔진은 읽혀지는 행의 위치를 나타내는 페이지 오프셋 테이블 엔트리와 같은 행의 내용이나 페이지 구조가 변경되지 않도록 유지해야 한다. 이러한 동작은 래치를 획득하고 메모리의 행으 관계 엔진에 전송하고 나서 래치를 해체함으로써 수행된다.
래치수가 많다는 것은 낮은 cache hit ratio로 인한 디스크 IO의 증가, 디스크의 병목을 초래하게 된다. 이 현상의 해결책 역시 쿼리 튜닝, 메모리 증가, 시스템 IO 대역폭 증가로 해결해야 한다.
1. Average Latch Wait Time(ms) : 요청된 래치에 대한 평균 래치 대기 시간
2. Latch Waits/Sec : 래치의 요청수
SqlServer:Lock 개체
1. Average Wait Time(ms) : 잠금이 대기하였던 평균 시간을 밀리초 단위로 나타냄
2. Lock Timeout /sec : 잠금을 얻기 위해 대기하면서 타임 아웃된 잠금 요청 횟수
3. Lock Waits/sec : 즉시 충족시킬 수 없고 잠금을 허가하기 위해서 호출자를 기다려야 하는 잠금 요청 횟수
4. Number of DeadLocks / sec : 교착상태를 일으킨 잠금수
데이터 베이스에서 Lock 메커니즘은 모든 쿼리와 데이터 액세스에 대해 데이터 무결성을 보장하며, 각각은 데이터 행 수준, 페이지 수준, 테이블 수준 또는 데이터베이스 수준으로 얻어질 수 있다. Lock 메커니즘은 응용프로그램과 쿼리가 어떻게 동작하고 공존하는지 또는 개별성과 동시성을 제공하기 위한 것이다. 체크해야할 중요한 카운터는Number of DeadLocks / sec 이다.
DeadLock 시점에서의 해결은 victim을 선택해야 하는 것이며 장기적인 해결을 하기 위한 접근은 아래와 같다. (또는 Set Daedlock_priority Low문을 사용하면 그 트랜잭션이 교착 상태 발생시 kill이 된다.)
1. 동일한 순서로 개체에 액세스한다.
2. 트랜잭션내에서 사용자 동작을 피한다.
3. 트랜잭션을 하나의 배치로 짧게 유지한다.
4. 가능한 낮은 격리 수준(Isolation level)을 사용한다. : Serializable < Read Committed
SQLServer:Memory Manager 개체
Memory Manager 개체는 Sql server가 할당된 메모리를 관리하는 방법에 대한 유용한 데이터를 제공한다. 각 프로세스는 데이터베이스에서 실행되기 때문에 메모리 자원을 요청하고 부여받는데, memory grants pending 카운터를 모니터링하면 얼마나 많은 사용자나 프로세스가 메모리 허가를 기다리고 있는지 알수 있다. Sql memory가 부족하면 더 많은 사용자나 프로세스가 메모리를 대기하게 되므로 Memory grants Pending값이 증가하게 된다.
1. Memory Grants Pending : 작업 공간 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수
2. Target Server Memory(kb) : sql Server가 사용할 수 있는 전체 메모리 양
3. Total Server Memory(kb) : Sql Server가 사용하고 있는 전체 메모리 양
SQLServer:SQL statistics 개체
1. Batch Request/sec : 서버가 받은 SQL 배치 요청 수
2. Sql Compilations/Sec : 초당 SQL Server가 SQL 문을 컴파일하는 수
3. SQL Re-Compilations/sec : 초당 SQL Server가 수행하는 SQL문의 재컴파일 수
Memory
Mssql 은 기본적으로 swap의 과정(ram <-> virtual memory간의 paging)을 하지 않는다. Ram, cache object를 사용하는 것으로 한다.
1. page faults / sec : 초당 프로세서에 의해 처리된 페이지 없음 오류 수. 하드페이지폴트(디스크 액세스를 요구함)와 소프트 페이지 폴트(페이지를 물리 메모리 내에서 찾음)를 포함
2. Page Reads/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽어온 횟수
3. Page Writes/sec : 물리적 메모리 공간을 해제하기 위해 페이지가 디스크에 쓰연 횟수
4. Pages/sec : 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽거나 쓴 페이지 수 이것은 (read + Write 카운터의 합)
포함해야할 자료
http://www.microsoft.com/korea/technet/iis/prfrelmn.mspx
HP Photosmart 2575 All-in-One 잉크호환표
2011. 12. 12. 16:53
IT-96(8767)
HP No.96 재생카트리지
C8767WA (NO.96) 재생카트리지
http://www.inktecmall.com/goods/view.php?seq=552
IT-97(9363)
HP NO.97 재생카트리지
C9363WA (NO.97) 재생카트리지
http://www.inktecmall.com/goods/view.php?seq=553
총구매금액 : 16,900원 (상품가격 14,400원 + 배송비 2,500 원 )
테스트에 필요성
2011. 12. 8. 19:31
xUnit 프레임워크를 만든 켄트 백은 "테스트란 개발자가 마음 편하게 잠자리에 들 수 있게 해 주는 것"이라고 했습니다. 지저분한 코드를 정리한다고 조금 손을 댔는데, 이것 때문에 혹시 기존 기능에 문제가 생기진 않을까 라는 불안한 마음으로 퇴근한 경험이 개발자라면 한 두 번쯤 있을 것입니다.또한 새로운 기능을 추가하고 적용하고 왔는데, 갑자기 회사에서 연락이 와서 그 기능 적용 이후로 다른 부분에서 많은 문제가 생겼으니 당장 해결해달라는 긴급 요청을 할 때도 있습니다.나는 셀 수도 없이 그런 경험을 많이 했습니다.
테스트는 하나의 프로그램밍이라고 생각의 전환이 필요한 것입니다.테스트를 실시간으로 주기적으로 할 수 있는 방법을 찾는 것이프로그램밍 기술을 향상시키는 방법인 것입니다.
xunit : X 단위
[보안] MD5의 새로운 취약점은 바로...구글 검색
2011. 12. 8. 18:28
보안뉴스에 MD5 암호화 관련해서 재미있는 기사가 나왔다.
MD5 해쉬된 패스워드의 원문을 구글 검색을 통해서 적은 노력으로 찾을수 있다고 한다.
아이디어가 정말 훌륭하다.
기사 : http://www.boannews.com/media/view.asp?idx=28850&kind=0
소스 : https://github.com/juuso/BozoCrack/blob/master/bozocrack.rb
BozoCrack / bozocrack.rb
require 'digest/md5'require 'net/http'class BozoCrackdef initialize(filename)@hashes = Array.new@cache = Hash.newFile.new(filename).each_line do |line|if m = line.chomp.match(/\b([a-fA-F0-9]{32})\b/)@hashes << m[1]endend@hashes.uniq!puts "Loaded #{@hashes.count} unique hashes"load_cacheenddef crack@hashes.each do |hash|if plaintext = @cache[hash]puts "#{hash}:#{plaintext}"nextendif plaintext = crack_single_hash(hash)puts "#{hash}:#{plaintext}"append_to_cache(hash, plaintext)endsleep 1endendprivatedef crack_single_hash(hash)response = Net::HTTP.get URI("http://www.google.com/search?q=#{hash}")wordlist = response.split(/\s+/)if plaintext = dictionary_attack(hash, wordlist)return plaintextendnilenddef dictionary_attack(hash, wordlist)wordlist.each do |word|if Digest::MD5.hexdigest(word) == hash.downcasereturn wordendendnilenddef load_cache(filename = "cache")if File.file? filenameFile.new(filename).each_line do |line|if m = line.chomp.match(/^([a-fA-F0-9]{32}):(.*)$/)@cache[m[1]] = m[2]endendendenddef append_to_cache(hash, plaintext, filename = "cache")File.open(filename, "a") do |file|file.write "#{hash}:#{plaintext}\n"endendendif ARGV.size == 1BozoCrack.new(ARGV[0]).crackelseputs "Usage example: ruby bozocrack.rb file_with_md5_hashes.txt"end
리팩토링
2011. 12. 7. 17:51
좋은 코드(Good Code)란?
나쁜 냄새(Bad Smell)가 나지 않는 코드
HTML5 & CSS3 reference
2011. 12. 7. 10:56
HTML5 & CSS3 속성별 브라우저 지원 보기
변경된 정보를 보다 쉽고 빠르게 찾을수 있습니다.
다양한 해상도를 가진 기기들에서도 확인 할수 있도록 미디어 쿼리도 반영이 되어 있다.
(반응형 웹 디자인)
http://html.nhndesign.com/html_guide/
html : hypertext markup language